Email remains the backbone of business communication - and one of the biggest attack vectors. Phishing, spoofing, and Business Email Compromise (BEC) cause billions in damages each year. But there is a well-defined technical flow that secures email end-to-end: the DMARC Flow. Understanding it step by step is the prerequisite for implementing it correctly.
Step 1 - The Sender Declares: SPF
Sender Policy Framework (SPF) is a DNS record that lists which mail servers are authorised to send email on behalf of your domain. When a receiving mail server gets a message claiming to be from you@example.com, it performs a DNS lookup for example.com’s SPF record and checks whether the connecting IP address is on the authorised list.
If the IP is not listed and SPF ends with -all (hard fail), SPF fails. With ~all (soft fail), the message is flagged but not outright rejected. SPF alone is not sufficient to stop domain spoofing, because SPF checks the envelope sender (the "Return-Path"), not the visible From header that users actually see.
Common SPF pitfalls that break the flow: exceeding the 10 DNS lookup limit, leaving stale includes from decommissioned providers, and forgetting to add new email-sending tools (CRMs, marketing platforms, transactional systems) to the record.
Step 2 - The Message Is Signed: DKIM
DomainKeys Identified Mail (DKIM) adds a cryptographic signature to every outgoing message. The sending mail server signs the message using a private key, and adds the signature as a header field. The corresponding public key is published in DNS under a selector record like selector1._domainkey.example.com.
When the receiving server gets the message, it fetches the public key from DNS and uses it to verify the signature. A valid signature proves two things: first, that the message came from a server in possession of the private key (i.e., an authorised sender); and second, that the message body and key headers were not modified in transit.
Unlike SPF, DKIM survives email forwarding, because it is tied to the message itself rather than the sending IP. This makes it a stronger signal for alignment. However, DKIM alone also cannot prevent domain spoofing - the signed domain must be aligned with the From header to count toward DMARC.
Step 3 - The Policy Is Enforced: DMARC
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the layer that ties SPF and DKIM together and makes them actionable. A DMARC record is a TXT record published at _dmarc.example.com that tells receiving servers three things:
- What to do with messages that fail both SPF and DKIM alignment - the policy (
p=none,p=quarantine, orp=reject). - Where to send aggregate reports (the
ruaparameter) - daily XML summaries from every major mailbox provider showing authentication results for all mail they received claiming to be from your domain. - Where to send forensic reports (the
rufparameter) - per-message failure reports for individual authentication failures.
The alignment check is the key concept. DMARC passes if either SPF alignment passes (the domain in the Return-Path matches the From domain) or DKIM alignment passes (the domain in the DKIM signature matches the From domain). An attacker forging your From header cannot pass alignment, because they cannot control your DNS or sign with your private key - so their message gets rejected.
The Three Policy Levels Explained
- p=none: Monitoring mode. Messages that fail DMARC are still delivered. Aggregate reports are sent to your rua address. This is the starting point - it gives you visibility before you take any enforcement action. Organisations should not stay at p=none for more than 30–60 days.
- p=quarantine: Messages that fail DMARC are sent to the spam/junk folder. This is the intermediate step that lets you verify no legitimate mail is being caught before moving to full rejection. Use the
pct=parameter to apply quarantine to only a percentage of failing mail initially. - p=reject: Messages that fail DMARC are outright refused by the receiving server. They never reach the inbox or spam folder. This is the only policy level that fully prevents domain spoofing. Google, Yahoo, and most insurers now treat p=reject as the expected baseline for established domains.
The Reporting Loop: Closing the Flow
What makes DMARC a flow rather than a one-time configuration is the reporting feedback loop. Every day, major providers - Gmail, Outlook, Yahoo, Apple Mail - send aggregate XML reports back to your rua address. These reports contain:
- The sending IP addresses and volumes
- The SPF and DKIM result for each source
- The DMARC disposition applied (none, quarantine, reject)
By analysing these reports, you discover unknown sending sources, identify misconfigured systems, and track your progress toward full enforcement. Without this feedback loop, you are flying blind - you have policies published but no idea whether they are working or catching legitimate mail.
DMARCFlow parses these XML reports automatically and presents them as readable dashboards, alerting you when new sources appear or when authentication rates drop unexpectedly.
Why the DMARC Flow Matters Beyond Security
Completing the DMARC flow - from SPF and DKIM through to p=reject with active monitoring - has benefits beyond stopping phishing:
- Inbox placement: Gmail and Yahoo’s bulk sender guidelines (effective 2024) require p=quarantine or higher for bulk senders. Domains without DMARC enforcement face increased spam filtering.
- Brand protection: Your domain cannot be used to send convincing phishing emails to your customers or partners once p=reject is in place. The reputational risk of a spoofing incident causing customer fraud is eliminated.
- Insurance and compliance: Cyber insurers and regulators (NIS2, ISO 27001, PCI DSS v4) treat DMARC enforcement as a baseline control. Domains at p=none are rated higher risk in underwriting models.
- BIMI eligibility: Brand Indicators for Message Identification - the feature that shows your logo in Gmail inboxes - requires DMARC at p=quarantine or p=reject as a prerequisite.