DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC is a robust email authentication protocol that builds upon SPF and DKIM to provide domain owners with enhanced protection against unauthorized email usage, such as phishing and spoofing attacks. By implementing DMARC, organizations can ensure their emails are properly authenticated and instruct receiving mail servers on how to handle messages that fail authentication checks.

How DMARC Works

DMARC operates by aligning the results of SPF and DKIM checks with the domain specified in the email's "From" header. When an email is received, the recipient's mail server performs SPF and DKIM validations. Based on the DMARC policy defined by the domain owner, the server then decides whether to accept, quarantine, or reject the email if it fails authentication.

Benefits of DMARC

Implementing DMARC offers multiple advantages that enhance your organization's email security and reputation:

Email Fraud Prevention

DMARC provides visibility into how your domain is used and prevents unauthorized senders from sending emails on behalf of your organization, effectively mitigating phishing and spoofing attacks.

Email Reliability

By ensuring that only authenticated emails reach recipients, DMARC establishes a foundation for reliable email delivery, reducing instances of legitimate emails being marked as spam or rejected.

Compliance

Many industries, governmental bodies, and cybersecurity insurance providers require DMARC implementation. Adhering to these standards ensures your organization meets necessary compliance requirements.

Enhanced Brand Reputation

Protecting your domain from unauthorized use reinforces trust with your audience, enhancing your brand's reliability and credibility in the digital space.

Key DMARC Record Components

Version (v)

Required. Specifies the DMARC version being used. The only valid value currently is v=DMARC1.

Example:
v=DMARC1
Copied to Clipboard!

Policy (p)

Required. Instructs the receiving mail server on how to handle messages that fail DMARC authentication.

Example:
p=reject
Copied to Clipboard!

Note: If your domain uses BIMI, the p option must be set to quarantine or reject. BIMI does not support DMARC policies with the p option set to none.

The available policies are:

  • none: Monitor emails without taking any action. Logs messages in a daily report sent to the email address specified with the rua option.
  • quarantine: Treat unauthenticated emails with suspicion, such as sending them to the recipient's spam folder. Recipients can review these messages to identify legitimate emails.
  • reject: Reject unauthenticated emails outright, preventing them from being delivered. The receiving server usually sends a bounce message to the sending server.

Percentage (pct)

Optional. Specifies the percentage of unauthenticated messages to which the DMARC policy is applied. This allows for gradual policy enforcement, minimizing the risk of legitimate emails being incorrectly handled. Valid values are between 1 and 100.

Example:
pct=100
Copied to Clipboard!

Note: If your domain uses BIMI, your DMARC policy must have a pct value of 100. BIMI does not support DMARC policies with the pct value set to less than 100.

Reporting URI for Aggregate Reports (rua)

Optional. Specifies the email address where aggregate DMARC reports are sent. These reports provide summaries of DMARC activity, helping domain owners understand email traffic and detect potential abuse.

Example:
rua=mailto:[email protected]
Copied to Clipboard!
  • It's recommended to use a dedicated mailbox, group, or third-party service such as KairOS DMARC Shield for handling reports to manage the high volume effectively.
  • To send reports to an email address in a different domain, add a TXT record to the email domain’s DNS. Refer to our DMARC reports page for more details.

Reporting URI for Forensic Reports (ruf)

Optional. The ruf tag is used to send failure reports, also known as forensic reports. These reports contain detailed information about individual email failures, allowing for more granular analysis and remediation.

Example:
ruf=mailto:[email protected]
Copied to Clipboard!

Subdomain Policy (sp)

Optional. Sets the DMARC policy for subdomains of your primary domain. Use this option if you want to apply a different DMARC policy to your subdomains.

Example:
sp=reject
Copied to Clipboard!
  • none: Monitor subdomain emails without taking any action. Logs messages in daily reports sent to the rua address.
  • quarantine: Treat unauthenticated subdomain emails with suspicion, such as sending them to the spam folder.
  • reject: Reject unauthenticated subdomain emails outright.

If not specified, subdomains inherit the DMARC policy set for the parent domain.

DKIM Alignment (adkim)

Optional. Sets the alignment policy for DKIM, defining how strictly the domain in the DKIM signature must align with the domain in the email's "From" header.

Example:
adkim=s
Copied to Clipboard!
  • s: Strict alignment. The sender domain must exactly match the d=domainname in the DKIM mail headers.
  • r: Relaxed alignment (default). Allows partial matches. Any valid subdomain of the d=domain in the DKIM mail headers is accepted.

SPF Alignment (aspf)

Optional. Sets the alignment policy for SPF, specifying how strictly the domain in the SPF signature must align with the domain in the email's "From" header.

Example:
aspf=s
Copied to Clipboard!
  • s: Strict alignment. The message From: header must exactly match the domain name in the SMTP MAIL FROM command.
  • r: Relaxed alignment (default). Allows partial matches. Any valid subdomain of the domain name is accepted.

Implementation Steps

  1. Create and configure SPF and DKIM records for your domain.
  2. Draft your DMARC policy based on your organization's email authentication strategy.
  3. Publish the DMARC record in your domain's DNS as a TXT record.
  4. Monitor aggregate and forensic reports to assess email authentication performance.
  5. Gradually enforce stricter DMARC policies as confidence in email authentication grows.
  6. Example DMARC Record:
    Record Name:
    _dmarc.example.com
    Copied to Clipboard!
    Record Type:
    TXT
    Copied to Clipboard!
    Record Value:
    v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; sp=reject; adkim=s; aspf=s;
    Copied to Clipboard!

    You can generate your own DMARC record using our Free Tools page.

Best Practices

Gradual Policy Enforcement

Start with a p=none policy to monitor email traffic without impacting delivery. Analyze the reports to understand how your domain is being used and identify legitimate emails. Gradually transition to p=quarantine and eventually p=reject as you gain confidence in your email authentication setup.

Regular Monitoring

Consistently review DMARC reports to identify unauthorized email sources and adjust your SPF and DKIM records accordingly. Regular monitoring ensures that your DMARC policy remains effective and adapts to any changes in your email infrastructure.

Common Challenges

Complex DNS Configurations

Setting up DMARC requires precise configuration of SPF and DKIM records. Misconfigurations can lead to legitimate emails being marked as spam or rejected. Ensure meticulous DNS setup and consider using specialized tools to validate your records.

Managing Multiple Email Sources

Organizations using multiple email service providers may find it challenging to maintain consistent SPF and DKIM configurations across all sources. Consolidate and regularly update your records to include all authorized senders, ensuring seamless email authentication.

Ready to Enhance Your Email Security?

Join our growing network of clients protecting their email communications with KairOS DMARC Shield — the trusted solution for securing your digital communications.

Sign Up Now