DMARC Explained: From Basics to Technical Specs + Examples

Domain-based Message Authentication, Reporting and Conformance (DMARC) is an email security protocol that helps prevent unauthorized use of your email domain. In simple terms, DMARC is like a policy and reporting system that sits on top of existing email authentication methods (SPF and DKIM) to ensure that only legitimate emails get delivered while fraudulent messages (like spoofed phishing emails) are blocked or flagged.

This article will start with a beginner-friendly overview of DMARC and then progressively dive into more technical details, including how it works with SPF/DKIM and why it’s especially important for SaaS companies.

What is DMARC? Explained simply

DMARC (which stands for Domain-based Message Authentication, Reporting & Conformance) is essentially a system that tells email receivers how to verify the source of an email and what to do if an email isn’t verified.

In everyday terms, think of DMARC as the instructions a domain owner gives to the world’s email providers: “If an email claims to be from my domain but can’t prove it, don’t trust it.”

It’s an email authentication protocol designed to combat email fraud and phishing by using the mechanisms of SPF and DKIM underneath. By leveraging these existing technologies, DMARC adds an extra layer of protection that links emails to the domain in the “From” address (the sender you see) and can enforce actions on suspicious emails.

How DMARC works during email delivery

Related terms

To understand how DMARC works under the hood, we need to briefly recall what SPF and DKIM do:

• SPF (Sender Policy Framework): SPF allows a domain owner to specify which mail servers or IP addresses are authorized to send emails on behalf of their domain. This is done via a DNS TXT record. You can read more in a separate article about SPF.
• DKIM (DomainKeys Identified Mail) adds a digital signature to emails to prove they came from your domain and weren’t changed on the way. Your domain’s public key is published in DNS, and each email is signed with a private key. The receiving server uses the public key to check that the message is authentic and unaltered. It’s like a security stamp that confirms the email is legitimate. You can read more in a separate article about DKIM.

Email flow step-by-step

• 1. The sender composes and sends an email
  • An email is sent from a domain – e.g., alice@company.com using an email service or server (like an app, SMTP server, or third-party provider).
• 2. The email travels to the recipient’s mail server
  • The message is routed through the internet and received by the destination mail server (e.g., Gmail, Outlook, etc.).
• 3. The recipient’s server checks for a DMARC record
  • The receiving server looks up the DNS records for the sender’s domain (company.com) and checks if a DMARC policy is published at _dmarc.company.com.
• 4. SPF check is performed
  • The recipient’s server retrieves the SPF record from company.com.
  • It checks if the sending server’s IP address is authorized to send emails for that domain.
  • Result: Pass or Fail
• 5. DKIM check is performed
  • The server looks for a DKIM signature in the email headers.
  • It retrieves the public DKIM key from the sender’s DNS and uses it to verify that the message hasn’t been altered and was authorized.
  • Result: Pass or Fail
• 6. DMARC alignment is evaluated
  • The recipient checks whether the domain used in SPF and/or DKIM matches (aligns with) the domain in the visible “From” address.
  • Alignment can be strict or relaxed, depending on the DMARC policy.
  • If either SPF or DKIM passes and aligns with the From domain, the message passes DMARC.
  • If neither passes and aligns, the message fails DMARC.
• 7. The recipient enforces the DMARC policy
  • Based on the sender’s DMARC policy (p=none, p=quarantine, or p=reject), the receiving server takes action:
  • None → Deliver the message normally (but log/report the failure).
  • Quarantine → Mark the message as spam or suspicious.
  • Reject → Block the message from being delivered.
  • You can read more details about DMARC policies in section DMARC Policies (detailed).
• 8. The recipient sends a DMARC report (if requested)
  • If the DMARC record includes a rua= tag, the recipient compiles an aggregate report of authentication results.
  • This report is emailed (usually daily) to the address specified in the DMARC record.
  • Optionally, if a ruf= tag is present, the server may send forensic/failure reports in real time.

Is DMARC necessary?

In short, DMARC isn’t legally mandatory in most cases, but in practice, it’s essential for email security, trust, and reliable delivery. DMARC is becoming increasingly important, especially for any organization that sends email using its own domain — like a SaaS company, brand, or business.

Why is DMARC important

Email remains a primary vector for cyberattacks, and businesses need to ensure their emails are both delivered to inboxes and protected from abuse. DMARC addresses both security and deliverability concerns. Here are some key benefits of implementing DMARC:

• Prevents domain spoofing & phishing: DMARC helps stop scammers from using your domain to send fake emails. It helps to verify that incoming messages actually come from the domain they claim. Interesting fact: Deloitte reports that 91% of cybercrimes start with a spoofed or phishing email. So blocking them is a crucial defense.
• Improves email deliverability: Using DMARC can increase the likelihood that your legitimate emails land in recipients’ inboxes rather than being flagged as spam. When email providers (like Gmail, Outlook, etc.) see that your domain has strict DMARC authentication in place, they trust your emails more.
• Protects brand trust: DMARC helps block fake emails pretending to be from your domain. This protects your reputation and prevents customer confusion or lost trust. Showing you have DMARC in place can also signal to clients and partners that you take email security seriously.

By combining these benefits, DMARC not only secures your email channel against impersonation attacks, but also helps ensure your real emails get delivered and trusted. It’s an industry best practice today — as of 2024, over half of all domains’ email volume was protected by DMARC. Businesses that implement DMARC have seen dramatic reductions in phishing emails pretending to be them.

Sample DMARC DNS record (+ its components explained)

To use DMARC, you publish a special DNS TXT record on your domain (specifically, on the subdomain _dmarc.yourdomain.com). This DMARC record contains a list of tags and values that define your policy and preferences. Let’s look at an example DMARC record and break down each part of it:

_dmarc.example.com. TXT “v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-errors@example.com; adkim=s; aspf=s; pct=100; sp=reject”

In this example (for "example.com"), the DMARC record is expressing a policy to reject failing emails, send reports to specified addresses, and some additional settings. Here’s what each component means:

• v=DMARC1 – This is the version tag and it’s required in every DMARC record. DMARC1 is currently the only valid version, so this tag is basically a fixed identifier that tells the email server “this is a DMARC record.” If the version tag is missing or incorrect, mail receivers will ignore the record.
• p=reject – The policy for the domain. In our example, it’s set to reject, meaning any email that fails DMARC authentication should be rejected (blocked) by receivers. The policy is the core of DMARC’s enforcement power: p can also be set to none (no special action, just monitor) or quarantine (treat failing mail as suspicious, typically send to spam). You can read more details about DMARC policies in section DMARC Policies (detailed).
• rua=mailto:dmarc-reports@example.com – The aggregate report address. This optional tag (rua) tells receivers where to send aggregate DMARC reports (RUA stands for “reporting URI for aggregate data”). In the record above, mailto:dmarc-reports@example.com is an email address that will receive XML summaries of DMARC results each day. You can list multiple addresses here, separated by commas, if you want reports sent to a team or a third-party analysis service.
• ruf=mailto:dmarc-errors@example.com – The forensic report address for message-specific failure reports (RUF = “reporting URI for forensic data”). This tag is optional. If specified, some receivers will send you real-time copies or detailed reports of emails that failed DMARC. You can read more details in section DMARC Reporting.
• adkim=s; aspf=s – These tags set the alignment mode for DKIM (adkim) and SPF (aspf). In the example both are s, which stands for “strict” alignment. That means the domain in the DKIM signature must exactly match the domain in the From address for DKIM to be considered aligned, and likewise the Return-Path (envelope) domain must exactly match for SPF alignment. The other possible value is r for “relaxed,” which is the default if these tags aren’t specified. “Relaxed” alignment means subdomains are allowed to count as a match (e.g., an email from notify.example.com could still align with example.com under relaxed mode). By setting strict alignment (s), example.com is choosing to be more restrictive — only emails from the exact domain qualify, not subdomains. Alignment settings are a way to fine-tune DMARC’s strictness.
• pct=100 – This tag stands for percentage. It specifies what percentage of emails should be subjected to the DMARC policy. pct=100 means the policy applies to all emails from the domain (100%). If, for example, you set pct=20, then only 20% of failing emails would actually have the policy applied (the rest would be treated as if p=none). This is an optional tag and is often used during a gradual rollout — for instance, you might start with pct=20 to only quarantine 20% of failing messages while monitoring the effect, then later increase to 100%. In our example, it’s 100 because we want full enforcement.
• sp=reject – The subdomain policy. This optional tag (sp) allows you to specify a different policy for your subdomains than the one you’ve set for the main domain. If sp is not set, subdomains typically inherit the top-level p policy by default. In the example, we’ve explicitly set sp=reject to apply a reject policy to all subdomains of example.com as well. This could be useful if, say, you wanted your primary domain at reject but were unsure about some subdomains (you could then set sp=quarantine or sp=none accordingly). In this case, since our main policy is reject, we’re just making it clear that subdomains should also reject failing email. (If your organization doesn’t send any email from subdomains, it’s common to set sp=reject to guard against abuse of any wildcard or unused subdomains.)

Together, these tags form a complete DMARC policy record. When published in DNS, it tells the world:

“This domain uses DMARC (v=DMARC1). Our policy is to reject unauthenticated emails (p=reject). Please send aggregate reports to dmarc-reports@example.com and forensic reports to dmarc-errors@example.com. We require strict alignment on DKIM/SPF (adkim=s; aspf=s). Apply this policy to 100% of messages, and use the same reject policy for any subdomains as well.”

Mail receivers like Gmail, Yahoo, Microsoft, etc. will reference this record when processing emails from example.com. They’ll enforce the specified policy and provide the requested reports. By analyzing the DMARC reports, the domain owner can verify that all legitimate email streams are passing authentication and see if any unauthorized sources are attempting to use the domain. Over time, this helps maintain a secure and reliable email ecosystem for the domain.

Note: In real-world scenarios, your DMARC record might be simpler or more complex depending on needs. At minimum, a DMARC record requires the v and p tags (and including a rua email is strongly recommended). Other tags like adkim, aspf, sp, pct, ruf, fo, etc., are optional and used for fine-tuning. Many organizations start with a basic DMARC record (e.g. v=DMARC1; p=none; rua=mailto:you@example.com;) and then evolve it. The example we provided above is a comprehensive one to illustrate various components.

DMARC Policies (detailed)

When a message fails the DMARC alignment test, DMARC allows the domain owner to specify what should happen next. This is defined in the DMARC policy published in DNS. There are three policy options a domain owner can choose:

• p=none: No special action is taken on failing emails. In practice, “none” means monitor only — the email is treated as if DMARC wasn’t in place (it may still be delivered, filtered, or rejected based on the receiver’s own spam rules), but you will receive DMARC reports about these messages.
• p=quarantine: Emails that fail DMARC should be accepted by the receiver but marked as suspicious — typically, they’ll be delivered to the spam/junk folder rather than the inbox. Quarantine is a step up from none: it tells receivers to flag or isolate failing messages (for example, Gmail might show a warning or send it to spam). This mitigates risk while still allowing the message to be seen by the user (just in case it was a legitimate email that failed due to a misconfiguration).
• p=reject: Emails that fail DMARC should be outright rejected (not delivered at all) by the receiving server. This is the strictest policy — essentially dropping emails that don’t pass the DMARC checks. A reject policy provides the highest protection against spoofed emails; messages that fail authentication will be bounced or discarded, never reaching the user’s inbox.

DMARC Reporting (detailed)

As mentioned, DMARC’s “R” stands for Reporting. There are two types of reports DMARC can send to the domain owner:

• Aggregate Reports (RUA): These are daily summary reports sent in XML format to the address specified in the rua tag of your DMARC record. Aggregate reports show high-level information about all the emails purporting to be from your domain: which IPs sent them, whether they passed SPF/DKIM, if they failed DMARC, etc. They do not include the actual email content, just statistics. For example, an aggregate report might say “100 emails received from IP X (claiming to be your domain), 90 passed, 10 failed SPF/DKIM and were quarantined.” These reports help you spot trends or unknown senders using your domain.
• Forensic Reports (RUF): Also known as failure reports, these are more detailed notifications sent in real-time (or near real-time) when an email fails DMARC. A forensic report might contain portions of the original email (such as headers or samples) that failed authentication, to help you investigate the cause. The ruf tag in the DMARC record specifies where to send these. For example, if someone tries to spoof your domain, you could get a forensic report containing the offending message’s details. In practice, forensic reports are optional and less commonly used, as some mailbox providers don’t send them due to privacy concerns. But if enabled, they can be very useful for incident response, providing a copy of a failed email for analysis.

Wrapping up

By now, you should have a solid understanding of what DMARC is and how it works — from the basic idea of verifying emails and blocking fakes, to the technical details of DNS records and policy enforcement. Implementing DMARC in the context of your email infrastructure can significantly bolster your security and improve email deliverability. It aligns the interests of senders and receivers in keeping email channels trustworthy. If you have any questions or need help with setting up your emails and DMARC, feel free to reach out at kristyna@sidemail.io.