SPF, DKIM, and DMARC can be deployed without stopping legitimate mail, but not as one DNS change made late in the evening. A safe rollout is a process: assign ownership, discover every sending source, correct authentication, observe reports, and only then enforce policy in stages. This guide expands on SPF, DKIM, and DMARC — protecting the company name in email.
DMARC reduces direct impersonation of a controlled domain in the visible From field. It does not establish that content is genuine and does not eliminate phishing. A message from a lookalike domain, a compromised real mailbox, or a legitimate service abused by a criminal may pass every check.
1. Establish prerequisites and ownership
Before changing records, appoint a business owner for the domain, a technical owner for DNS and email, and an owner for every sending system. Decide who analyses reports, approves each stage, and manages rollback. Protect the registrar, DNS, gateway, and provider consoles with MFA, and give at least two authorised people access.
You need:
- a list of company domains and subdomains, and control of public DNS;
- a mailbox or service receiving DMARC aggregate reports;
- an observation window covering a complete business cycle;
- a change, test, approval, and rollback procedure;
- contacts for owners and support teams of external platforms.
Record existing SPF records, DKIM selectors, DMARC, volumes, and delivery problems. Lowering TTL helps with a planned change but does not guarantee immediate cache refresh.
2. Inventory every sender
Do not base the inventory solely on the primary Microsoft 365 or Google Workspace tenant. A domain may be used by CRM, newsletters, invoicing, HR, helpdesk, a shop, web form, scanner, monitoring, cloud application, and supplier server. Include periodic invoices, statements, campaigns, password resets, and alerts.
For each source, record:
- owners, visible
Fromdomain, and envelope-from/MAIL FROM; - DKIM signing domain and selector;
- provider, source IPs, and approximate volume;
- production, test, and standby environments;
- test recipients and a way to roll back the source.
Discover sources through configuration, gateway logs, headers from real messages, supplier contracts, discussions with departments, and DMARC reports. A report showing an unknown IP address starts an investigation; it is not automatic proof of an attack. It may be a forgotten legitimate service, shared provider infrastructure, or actual spoofing.
3. Correct SPF and the technical return path
SPF is evaluated for the domain used as MAIL FROM in the SMTP transaction, usually exposed later in the Return-Path header. When MAIL FROM is empty, as it is for some delivery-status messages, a receiver can evaluate the HELO/EHLO domain. This identity is not automatically the domain in the visible From header. Consequently, “SPF pass” alone is insufficient for DMARC: the SPF-authenticated domain must also align with the From domain.
One DNS name should have one SPF TXT record beginning with v=spf1. The ip4, ip6, a, mx, include, exists, and redirect terms have different effects. Do not copy a provider record without understanding it; an include can introduce changing source sets.
SPF limits mechanisms and modifiers that cause DNS lookups to ten per evaluation. This includes include, a, mx, exists, and redirect, including through nesting; it is not the number of words or all DNS packets. Exceeding it can produce permerror. ip4 and ip6 do not themselves consume the limit, but manually “flattening” dynamic ranges requires tracking provider changes.
Ideally, a provider should support a company-controlled, aligned return-path subdomain. Remove obsolete sources, avoid a broad +all, document every include, and test the record before publication. SPF is path-dependent: ordinary forwarding often changes the sending server and can break SPF even when the original message was legitimate.
4. Enable DKIM and manage key lifecycles
DKIM signs selected headers and the body. The signing domain appears in the d= parameter and the selector in s=; the public key is published at selector._domainkey.domain. For DMARC, a valid signature alone is not enough: the d= domain must also align with the visible From domain.
Each significant provider should sign with the customer’s domain when supported. Prefer current key types and lengths supported by provider and recipients. The private key remains in the signing system; DNS contains the public key. Separate selectors by provider or environment.
A key lifecycle includes generation, activation, verification, rotation, incident revocation, and delayed removal of the old key. Rotate with two selectors: publish the new key, enable and verify signatures, wait for the agreed period, then remove the old record. Record owner, provider, dates, and algorithm; do not assume a provider rotates for the customer.
5. Understand alignment and the DMARC pass condition
DMARC evaluates the domain in the visible From header. A message passes DMARC when at least one path satisfies both requirements:
- SPF authenticates a domain and that domain aligns with
From; or - DKIM authenticates a signature and its
d=domain aligns withFrom.
SPF and DKIM do not both have to pass. Conversely, both can technically pass while DMARC fails if neither authenticated domain aligns. Alignment is relaxed by default: the domains may share the same organisational domain. Strict mode requires a closer match and should only be selected with a deliberate justification.
6. Start with p=none and aggregate reports
Publish a record at _dmarc.domain with v=DMARC1, p=none, and a controlled rua address. p=none asks receivers to report without requesting quarantine or rejection; it is not an enforcing protection. The reporting address may receive large XML attachments, so use a dedicated, monitored mailbox or processor, set retention, and restrict access. Sending reports to another domain may require additional DNS authorisation by the report recipient.
Aggregate reports show message counts grouped primarily by source IP and policy result. They also include the From domain, SPF/DKIM domains and results, disposition, and sometimes a receiver override. They are not message copies, complete logs, or a guarantee that every receiver reports.
Normalise the data and inspect trends. For every significant row, identify the owner, expected volume, SPF result, DKIM signature, alignment, and receiver decision. Remain at p=none for a full cycle that includes infrequent sends. A high overall pass percentage is insufficient if the small set of failures contains invoices, password resets, or executive mail.
7. Fix legitimate sources and vendors
Correct configuration at the source first. Set an aligned return path, activate DKIM in the company’s domain, remove obsolete include terms, and correct the visible From domain. Do not authorise an entire broad infrastructure merely to hide one configuration fault. If a provider supports neither alignment nor customer-domain DKIM, consider a dedicated subdomain, another sending method, or another provider. Contracts should state requirements for domains, keys, logs, change notifications, and service termination.
Forwarding can break SPF because an intermediary sends from another IP. DKIM survives more often, but a list or gateway modifying content or signed headers can invalidate it. ARC can carry earlier results, but depends on receiver trust and does not replace DMARC. Test real paths; do not create a global exception.
8. Enforce policy in stages
After fixing sources, move to p=quarantine, initially with a limited pct, such as 10 or 25. pct is the requested percentage of DMARC-failing messages to which a receiver should apply the policy; it is not a precise deployment mechanism or a guarantee of every receiver’s behaviour. Increase only after reviewing reports and support cases: 25, 50, then 100 percent. Move to p=reject in the same controlled manner.
The organisational domain’s policy can cover subdomains through sp. Subdomains used by independent platforms can be separated and prepared individually; unused subdomains may receive a strict policy earlier after confirming that they truly send no mail. Do not treat sp or pct as a substitute for inventory. Each stage needs a date, entry and exit criteria, an owner, approval, and an observation period.
9. Test, control changes, and prepare rollback
Before each stage, send controlled messages from every source to several independent receivers. Inspect complete headers: Authentication-Results, Received-SPF, DKIM-Signature, Return-Path, and visible From. Test replies, forwarding, automated messages, empty MAIL FROM, large campaigns, and the standby environment. Confirm correct alignment, not merely successful delivery.
The change record should contain the record before and after, TTL, approval, tests, incident channel, and rollback trigger. Rollback may mean reducing pct, returning to quarantine or none, restoring a selector, or stopping a faulty sender. Do not remove sound controls because of one source; DNS caching delays rollout and rollback.
10. Continue monitoring after reject
p=reject does not end the project. Review reports, new sources, volumes, SPF errors, selectors, and rotation dates. Assess email when procuring and retiring services. Alert on a large new source, lost alignment, fewer signatures, and DNS changes. Periodically test critical paths and account access.
DMARC does not protect lookalike domains the organisation does not control, and it does not stop an attacker using a compromised real mailbox. MFA, account protection, sign-in monitoring, training, and a safe payment process remain necessary. Confirm a changed bank account or urgent transfer over a second channel, using a previously known number and two-person approval; the bank-detail change verification card provides a concise procedure.
If inventory, DNS dependencies, or responsibility are unclear, a security assessment can structure the scope, while system administration can cover ongoing DNS and mail-platform operation. The broader protection of accounts, processes, and incident response belongs within cybersecurity services.