Email Authentication: SPF, DKIM & DMARC

A domain's email authentication configuration determines whether receiving mail servers can verify that a message originated from an authorized source. Three DNS records govern this: SPF lists the IP addresses and services authorized to send as your domain; DKIM attaches a cryptographic signature to each outbound message; and DMARC defines the policy when either check fails. Without DMARC enforcement, receiving servers have no instruction from your domain on how to handle unauthenticated senders, including senders using your domain in the From field.

For businesses that depend on email, including marketing campaigns, transactional confirmations, and password resets, the authentication layer has a direct deliverability dimension. Inbox providers weight domain reputation signals when routing mail. A domain associated with unauthenticated sending patterns will see degraded deliverability across all outbound email from that domain, not only the unauthenticated messages.

SPF, DKIM, and DMARC each have a distinct role and a required configuration sequence. DMARC enforcement depends on SPF and DKIM alignment being in place first: setting p=reject before the sending source inventory is aligned causes legitimate email to fail authentication. The rest of this post covers what each record does, what each configuration state produces, and how to reach full enforcement without disrupting deliverability.

The Three Records Your Email Deliverability Depends On

Each record lives in your domain's DNS, the same place your website's address, nameservers, and MX records live. They work as a stack: SPF and DKIM are the authentication layers, and DMARC is the policy that tells receiving mail servers what to do when authentication fails.

The three records are interdependent. DMARC enforcement only works if SPF and DKIM are configured correctly first. Getting to full protection requires doing them in the right order, and understanding what breaks at each step if you skip ahead.

What Actually Happens Without SPF

SPF is your domain's authorized sender list. Without it, there is no list. Any mail server anywhere in the world can send email claiming to be from your domain, and receiving mail servers have nothing to check against. The check doesn't fail. It doesn't happen.

The qualifier at the end of the SPF record determines how receiving servers treat senders not on the list. ~all (softfail) marks unauthorized senders as suspicious but still allows delivery. -all (hardfail) instructs receiving servers to treat unauthorized senders as unauthorized. SPF authorization is defined by the record's include mechanisms; enforcement behavior is set by the qualifier.

SPF has a structural constraint: only one SPF record is permitted per domain. Klaviyo, Shopify, Mailchimp, and other sending platforms each instruct users to add their SPF include to the existing record. Adding a new TXT record instead of editing the existing one produces two SPF records in DNS. Two SPF records result in PermError: authentication fails for every message from every sender, regardless of whether the source is authorized.

How DKIM Proves an Email Came From You

Think of a wax seal on a letter. A signet ring creates a seal that's unique to the sender. The recipient can look at it, recognize it, and know the letter came from you and wasn't tampered with after it was sealed. DKIM works the same way, using mathematics instead of wax.

Every time your mail platform sends an email on your behalf, it signs the message using a private key that only it controls. The signature is attached to the email's headers. When the message arrives, the receiving mail server checks your DNS for the corresponding public key and uses it to verify the signature. If it checks out, the email is confirmed to have come from your authorized platform and hasn't been modified in transit.

DKIM has one important advantage over SPF: it survives simple email forwarding. SPF checks the IP address of the sending server. When an email is forwarded, the IP changes to the forwarding server's IP, and SPF fails — even if the original message was fully legitimate. DKIM's signature travels with the message and remains valid as long as the headers and body aren't modified in transit. This is why DKIM alignment is more reliable for direct forwarding scenarios — sales tools, executive assistants forwarding from one account to another. Mailing lists are a different case: list servers frequently append footers, modify Subject lines, or rewrite Reply-To headers, which invalidates the DKIM signature.

Why Flipping Straight to p=reject Will Break Your Email

p=reject instructs receiving mail servers to reject any message from your domain that fails authentication at the SMTP layer — the message never reaches the inbox. That behavior is the goal. The prerequisite is that every legitimate sending source is aligned under SPF and DKIM before the policy goes live.

If Shopify, Klaviyo, Mailchimp, Postmark, or any other sending platform isn't in your SPF record and DKIM-signed before p=reject is set, those platforms' mail fails authentication. Order confirmations, shipping notifications, abandoned cart sequences, and password resets route through those platforms — each unauthenticated source becomes a deliverability failure under p=reject.

The purpose of p=none — the monitoring mode — is not to be a permanent destination. It's to give you time to build a complete picture of every source sending email as your domain before enforcement goes live. DMARC sends aggregate reports to whichever address you configure in the rua= field. Those reports, parsed and reviewed, tell you which senders are passing authentication and which are failing — before you do anything that would block them.

Organizations that stay at p=none indefinitely have typically left aggregate reports unread, left SPF and DKIM alignment unfinished, and accumulated a sending source inventory that will cause failures the moment enforcement goes live. The monitoring phase exists to close those gaps before they become enforcement problems.

A Quick Self-Check: Where Does Your Domain Stand?

Three records, three states each. Here's what each state means for your deliverability and your exposure.

The Staged Path to Enforcement

Moving from no enforcement to p=reject safely requires a phased approach gated on real data — not calendar dates. Each phase has a minimum hold time and an alignment threshold derived from DMARC aggregate reports. The threshold must be met before advancing. The logic is simple: if 5% of your email is failing authentication, you haven't finished aligning your sending sources, and enforcing now means losing 5% of your legitimate mail.

"p=none serves one purpose: build a complete inventory of every source sending as your domain before enforcement decisions make any gap permanent."

Each phase gate is driven by verified alignment percentages from DMARC aggregate reports, not by arbitrary wait times. The gating prevents common mistakes — like advancing to p=reject while a third-party sending source is still misaligned, which would block its mail silently.

The phased model is how fedlin.com itself reached full enforcement — the same process used for client domains. Phase 1 monitoring is also where configuration errors get caught before they matter. A real example: a client domain reached out for deployment with two SPF records in DNS — a PermError condition that was silently breaking authentication for all their email. That was caught and resolved during Phase 1, before any enforcement policy was in place to cause damage.