Email Authentication: SPF, DKIM, and DMARC Without the Headache

Why spoofing works when email is left unauthenticated

The protocol that carries most business email, SMTP, was designed in an era of mutual trust between a handful of research hosts. It has no built-in way to prove that the address in the From line belongs to the server that sent the message. Anyone can compose a message that claims to come from your CEO, your billing department, or your domain's automated no-reply address, and a receiving server that performs no authentication will place it in the inbox looking entirely legitimate.

This is why display-name impersonation and exact-domain spoofing remain the opening move in so much business email compromise. Verizon's Data Breach Investigations Report has, year after year, tied the majority of breaches to a human element, and a message that appears to come from a trusted internal address is exactly the lure that defeats a busy employee's judgment. The fix is not more suspicion from people. It is making forgery of your domain provably fail before the message is ever delivered. Three DNS-published standards do that, and the important thing to understand up front is that they only work as a set.

The three records, and what each one actually proves

Each standard answers a different question, and each has a blind spot that the next one covers.

• SPF (Sender Policy Framework) publishes, in a DNS TXT record, the list of IP addresses and hosts authorized to send mail for your domain. A receiver checks the sending server against that list. Its blind spot: SPF validates the hidden envelope sender (the return-path), not the visible From address a human reads, and it breaks when mail is forwarded because the forwarding server is not on your list.
• DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to each message using a private key; the matching public key lives in DNS under a named selector. A receiver verifies that the signed portions were not altered in transit and did originate from a key your domain controls. Its blind spot: a valid signature proves integrity, but on its own it does not require the signing domain to match the From address, so a signed message can still carry a forged visible sender.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties the two together. It requires that SPF or DKIM not only pass but align with the domain in the visible From address, tells receivers what to do when that check fails, and asks them to send you reports. This is the piece that actually stops spoofing of your own domain, and it is the piece most organizations never finish deploying.

Figure: SPF and DKIM each prove one thing; DMARC binds both to the visible sender, which is what turns three passing checks into genuine assurance.

Publishing SPF and DKIM alone feels like progress, but without an enforced DMARC policy a receiver has no instruction to reject a message that fails, and no requirement that the passing authentication even belongs to the domain the user sees. That gap is the whole game. A disciplined cyber security program treats these three records as a single control, not three optional boxes.

Alignment: the gotcha that breaks most first attempts

Alignment is the concept that trips up nearly every rollout, so it is worth being precise. DMARC does not care merely that SPF or DKIM passed. It cares that the domain they authenticated matches the organizational domain in the From header.

• SPF alignment compares the return-path domain to the From domain. A marketing platform that sends "as" you but stamps its own return-path will pass SPF for its domain yet fail SPF alignment for yours.
• DKIM alignment compares the domain in the signature (the d= value) to the From domain. A vendor that signs with its own domain rather than yours passes DKIM but fails alignment.

Only one of the two needs to align for DMARC to pass, which is why DKIM is the more resilient anchor: its signature survives forwarding, where SPF does not. Two settings control strictness. The adkim and aspf tags can be set to relaxed (the default, which allows subdomains of your organizational domain to align) or strict (which demands an exact match). Most organizations should stay relaxed. The practical takeaway: get every legitimate sender to either sign with your domain or use a return-path under your domain, and treat DKIM alignment as the goal for anything that is forwarded.

A safe rollout: none, then quarantine, then reject

The single biggest mistake we see is a DMARC record parked at p=none forever. Monitor-only mode reports on failures but blocks nothing, so spoofing continues unabated. The other failure mode is the opposite: jumping straight to p=reject and silently dropping legitimate invoices, password resets, and newsletters because a real sender was never aligned. The safe path is deliberate and staged, and for most organizations it runs six to ten weeks.

1. Inventory your senders first. List every system that sends mail as you: your mail platform, marketing and CRM tools, ticketing and payroll systems, invoicing, and any application relays. This list is always longer than people expect.
2. Publish SPF and DKIM for each legitimate sender. Add authorized hosts to SPF and enable DKIM signing on every platform that supports it, using your domain in the signature where possible.
3. Publish DMARC at p=none with reporting on. Set a rua address to receive aggregate reports. You are now collecting evidence, not enforcing.
4. Read the reports and fix alignment. Over two to four weeks, confirm every legitimate source is authenticating and aligned. Fix or retire the ones that are not.
5. Move to p=quarantine, ramping with pct. Start enforcing on a fraction of failing mail (for example pct=25), watch for fallout, then raise toward 100 percent. Quarantined mail lands in spam rather than vanishing, which gives you a safety margin.
6. Move to p=reject. Once quarantine is clean, reject outright. Failing mail is now refused at the receiver, and exact-domain spoofing of your domain stops working.

Use the sp tag to set a policy for subdomains explicitly; attackers love to spoof unused subdomains that inherit a weak policy. A wildcard-style stance of sp=reject closes that door.

Reading the aggregate reports

Aggregate reports arrive as XML from receiving providers, one file per reporting window, summarizing which sources sent mail claiming your domain and whether they passed SPF, DKIM, and alignment. Raw XML is unpleasant to read at volume, so route the rua mailbox into a DMARC analytics tool or a managed helpdesk and IT support workflow that parses and trends it. What you are looking for:

• Legitimate sources that are failing alignment (fix these before enforcing).
• Unknown IP addresses passing your authentication (a possible misconfiguration or a shadow-IT sender to bring under control).
• Unknown IP addresses failing authentication (often the spoofing you are trying to stop, and useful signal in its own right).

Forensic reports, requested with the ruf tag, provide per-message detail but carry privacy considerations and are supported by fewer providers; aggregate reports do most of the work.

BIMI: the payoff for getting to reject

Brand Indicators for Message Identification (BIMI) lets your verified logo render next to your messages in supporting inbox clients. It is not a security control on its own, but it is a tangible reward for finishing the job, because it requires an enforced DMARC policy of p=quarantine or p=reject before it will display. Most major providers also require a Verified Mark Certificate, which attests that you own the trademarked logo. The result raises the cost of impersonation and gives recipients a visible trust cue, but treat it strictly as the last step after enforcement, never a shortcut to it.

Getting to reject, and staying there

Email authentication is one of the highest-return controls in security: a few DNS records, deployed in the right order, that permanently defeat exact-domain spoofing. The work is not the syntax; it is the discipline of inventorying senders, fixing alignment, and moving through none, quarantine, and reject without breaking legitimate mail. Pair it with ongoing security awareness training so people stay alert to the impersonation attempts that use look-alike domains DMARC cannot touch.

If you want your domains taken from an unenforced record to a monitored p=reject without disrupting a single legitimate sender, talk to intSignal's security team for a sender inventory and a staged rollout plan.