DNS and email authentication: SPF, DKIM, and DMARC

SPF, DKIM, and DMARC are three different controls with one shared job: help a receiving mail system decide whether a message using your domain is legitimate. Publishing a record from a generator is the easy part. Finding every copier, ticketing platform, payroll service, website form, and marketing tool that sends as your company is the real project.

Do this in the wrong order and you can reject your own invoices. Do it carefully and attackers have a much harder time impersonating your visible From address.

1. Inventory every sending source

Start with systems, not DNS. For each domain, list:

• Microsoft 365, Google Workspace, or another primary mail host
• Marketing and customer-notification platforms
• Website forms, CRM, help desk, and invoicing systems
• Scanners, copiers, monitoring tools, and line-of-business applications
• Vendors that send mail with your domain in the visible From address

Record who owns each source, how it authenticates, and whether it still needs to exist. Do not add a mystery sender to SPF simply because it appeared in a report. Confirm the business owner first.

This inventory should include domains that do not send mail. A parked brand domain can still be spoofed, and a deliberate no-mail policy is better than silence.

2. Build one valid SPF policy

SPF authorizes servers to use a domain in the SMTP envelope, commonly exposed as Return-Path. It does not directly protect the visible From address by itself.

Your DNS should contain one SPF TXT record for a given name, beginning with v=spf1. Add only the IP addresses and provider mechanisms required by the sources you confirmed. End the record according to the policy you intend to publish; -all means other senders are not authorized.

RFC 7208 imposes a limit of 10 mechanisms and modifiers that trigger DNS lookups during evaluation. Nested include records count. Exceeding the limit returns a permanent error, so an SPF record with six visible includes can still be broken several layers down.

Practical rules:

• Keep one record; do not publish separate SPF records for separate providers.
• Remove services you no longer use instead of accumulating includes forever.
• Avoid broad a and mx authorization unless those hosts genuinely send mail.
• Recalculate the lookup path whenever a provider changes its SPF guidance.

SPF often breaks on forwarding because the forwarding server becomes the connecting sender. That is one reason DKIM matters.

3. Enable DKIM on every capable sender

DKIM adds a cryptographic signature to selected message headers and the body. The receiver retrieves the public key from DNS and verifies that the signed content was not altered. The current DKIM standard, RFC 6376, uses a signing domain (d=) and selector (s=) to locate that key.

For each mail platform:

1. Generate or enable the provider’s DKIM configuration.
2. Publish the TXT or CNAME records it supplies for the selector.
3. Turn on signing in the provider console; publishing the key alone does nothing.
4. Send an external test and inspect the authentication results for dkim=pass.

The signing domain should align with the domain users see in From. A third-party platform can produce a perfectly valid DKIM signature for its own domain and still fail your DMARC check because the identity is not aligned.

Selectors allow key rotation. Keep the old selector available during the transition, confirm new mail uses the new selector, and then retire the old record. Do not delete the only public key while queued messages are still in transit.

4. Add DMARC in monitoring mode

DMARC evaluates the visible From domain. A message passes DMARC when at least one of these paths succeeds and aligns with that From domain:

• SPF passes using an aligned envelope domain.
• DKIM passes using an aligned signing domain.

The current specification is RFC 9989, published in 2026 and replacing RFC 7489. It recommends using both SPF and DKIM underneath DMARC, even though only one aligned path must pass for an individual message.

Start with a record at _dmarc.example.com similar to:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

p=none is monitoring mode. It asks participating receivers for aggregate reports without asking them to quarantine or reject based on DMARC. Use a dedicated, protected mailbox or a reputable report processor; raw aggregate XML becomes noisy quickly.

Analyze a full business cycle. Identify legitimate sources, fix alignment, and confirm that low-volume systems such as monthly billing and annual benefits notices are represented. Reports describe what receivers observed; they are not a list of systems you should automatically authorize.

5. Move deliberately to enforcement

Once legitimate streams consistently pass, change the policy to p=quarantine, review the impact, and then move to p=reject. Enforcement tells receivers what you want done with mail that fails DMARC, but receivers retain their own handling discretion.

Check subdomains too. Decide whether applications should send from the organizational domain, a dedicated subdomain, or not at all. Separate subdomains can make third-party ownership clearer without granting one vendor authority over every sender.

Do not jump to reject because an online checker turned green. DNS syntax can be perfect while a payroll system signs with the wrong domain.

6. Verify after every change

After DNS has propagated:

• Query the SPF, DKIM selector, and _dmarc TXT records from more than one resolver.
• Send real tests through each source to external mailboxes.
• Inspect message headers for SPF, DKIM, DMARC, and alignment results.
• Watch aggregate reports for new and failing sources.
• Put an owner and review date beside every authorized platform.

Treat mail-authentication changes like production changes. Record the old value, new value, reason, owner, and rollback path. Our one-page change documentation pattern works just as well for DNS as it does for firewalls.

SPF, DKIM, and DMARC improve domain authentication; they do not replace mailbox MFA, anti-phishing controls, or user verification of payment changes. They also solve a different problem from DNS security filtering, despite both relying on DNS.

Bottom line: inventory every sender, keep SPF within its lookup limit, enable aligned DKIM signing, use DMARC reports to find gaps, and enforce only after legitimate mail is clean. The record is one line. The work is knowing what is allowed to send it.