Introduction to DMARC 

In today’s digital landscape, email remains one of the most widely used communication channels for businesses, but it is also the most exploited by cybercriminals. Threats like email spoofing, phishing, and business email compromise (BEC) continue to rise, leading to financial losses, data breaches, and reputational damage.  To counter these threats, organizations need a robust way to ensure that only legitimate emails are delivered under their domain name. This is where DMARC (Domain-based Message Authentication, Reporting, and Conformance) comes into play.  DMARC is an open email authentication standard that works in conjunction with SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). It allows domain owners to publish policies that instruct receiving mail servers how to handle emails that fail authentication checks-whether to monitor, quarantine, or reject them.  By implementing DMARC, organizations can: 

• Prevent email spoofing and phishing attempts using their domain. 

• Protect brand reputation by ensuring customers and partners only receive genuine emails. 

• Improve email deliverability, since authenticated emails are more trusted by providers like Microsoft, Google, and Yahoo. 

• Gain visibility through detailed reporting on how their domain is being used across the email ecosystem. 

This diagram illustrates the key components involved in email authentication using SPF, DKIM, and DMARC protocols. 

• The sender’s mail server publishes the SPF DNS record and uses a private DKIM signing key to sign outgoing emails. 

• When the email is sent, it carries both SPF and DKIM signatures to the recipient’s mail server. 

• The recipient’s mail server performs an SPF check to verify the sending IP against the SPF DNS record. 

• It then performs DKIM verification to confirm the email signature using the public key published in DNS. 

• A DMARC policy check is conducted to ensure alignment of SPF and DKIM results and to enforce the sender’s policy. 

• If all validations succeed, the email is authenticated and delivered; if not, it is rejected or marked as spam for security 

Prerequisites 

Configuring SPF Before Implementing DMARC 

Before deploying DMARC, it is essential to ensure that your domain has a properly configured SPF (Sender Policy Framework) record.  SPF is an email authentication method that allows domain owners to define which mail servers are authorized to send emails on behalf of their domain. This record is published in the DNS and acts as a permission list for outgoing emails.  When a receiving mail server gets an email claiming to come from your domain, it checks the SPF record to confirm whether the sending server’s IP address is included in the authorized list. If it is not, the email may be marked as suspicious or rejected. 

Implementing SPF before DMARC is critical because: 

• DMARC relies on SPF (and DKIM) for validation. Without SPF, DMARC policies cannot be fully enforced. 

• It ensures that only legitimate sources (like your mail servers, Microsoft 365, or Google Workspace) are allowed to send on behalf of your domain. 

• It reduces the risk of spoofed emails reaching your customers and partners. 

  This Figure shows the SPF record configured as a TXT record in GoDaddy’s DNS management console: 

• Record Type: TXT 

• Host: @ (represents the root domain) 

• Value: v=spf1 include:spf.protection.outlook.com -all 

• TTL: 1 Hour (Time to Live, sets DNS caching duration) 

This record means that emails sent from servers listed in spf.protection.outlook.com are allowed, and all others should be rejected. 

Enabling DKIM Before Implementing DMARC 

Alongside SPF, it is equally important to enable DKIM (DomainKeys Identified Mail) on your sending domain before deploying DMARC.  DKIM adds a cryptographic signature to every outbound email. This signature is validated by receiving mail servers using a public key that is published in your domain’s DNS. If the signature matches, it confirms that the email has not been altered during transit and that it truly originates from the authorized domain. 

Enabling DKIM ensures: 

• Message integrity: The content of the email (subject, body, attachments) has not been tampered with. 

• Domain authenticity: Proves that the message was genuinely sent from your domain and not forged. 

• Improved trust and deliverability: Emails signed with DKIM are less likely to be flagged as spam by providers like Google, Microsoft, and Yahoo. 

• Stronger DMARC enforcement: Since DMARC relies on both SPF and DKIM for alignment checks, enabling DKIM is necessary for full protection. 

This figure shows the DKIM CNAME records configured in GoDaddy’s DNS management console: 

• Record Type: CNAME 

• Host: 

                     selector1._domainkey  selector2._domainkey 

• Value: 

                     selector1-Example-com._domainkey.Example.dkim.mail.microsoft.                      

                     selector2-conslteklabs-com._domainkey. Example.dkim.mail.microsoft. 

• TTL: 1 Hour 

These records direct recipient mail servers to the mail provider’s public DKIM key for signature verification. By configuring these CNAME records, outgoing emails are digitally signed, and recipient servers can validate the signature for authenticity. 

Identify All Legitimate Email Sources and Third-Party Services 

Before enforcing DMARC, it’s essential to have full visibility into who is legitimately sending emails on behalf of your domain. Many organizations use multiple systems beyond their primary mail server to send emails such as marketing platforms, CRM tools, helpdesk software, and cloud services. If these sources are not properly identified and authenticated, DMARC could mistakenly block legitimate emails.   

How to Identify Legitimate Email Sources 

Internal Email Servers: 

• Microsoft 365 / Exchange Online 

• Google Workspace (Gmail) 

• On-premises Exchange servers 

Third-Party Services: 

• Marketing tools (e.g., Mailchimp, SendGrid, HubSpot) 

• CRM platforms (e.g., Salesforce, Zoho) 

• Helpdesk systems (e.g., Zendesk, Freshdesk) 

• Security platforms (e.g., Proofpoint, Barracuda, Mimecast) 

• Transactional mailers (e.g., Amazon SES, Postmark, Mandrill) 

Device or Application Senders: 

• Printers and scanners (for scan-to-email) 

• ERP or billing systems that generate invoices or alerts 

• Monitoring systems that send automated notifications 

Why it is Important:

• Ensures all legitimate senders are included in your SPF records and configured with DKIM signing. 

• Prevents legitimate business emails from being quarantined or rejected by DMARC. 

• Helps maintain smooth communication with customers, vendors, and internal teams. 

How DMARC Works?

DMARC acts as an additional layer of protection on top of SPF and DKIM, ensuring that only legitimate emails are delivered under your domain name. Here’s how it works in simple terms: 

Verification with SPF and DKIM 

• When an email is received, the mail server checks if it passes SPF (authorized sending server) or DKIM (valid digital signature). 

• At least one of these checks must align with the domain in the “From” address. 

Policy Enforcement:

• Based on the DMARC record published in your domain’s DNS, the receiving server enforces one of the following policies: 

1. None: Monitor only, take no action.
2. quarantine: Send suspicious emails to the spam/junk folder.
3. reject: Block and discard unauthenticated emails. 

Reporting & Feedback 

1. DMARC generates two types of reports: 

          Identify All Legitimate Email Sources and Third-Party Services 

Before enforcing DMARC, it’s essential to have full visibility into who is legitimately sending emails on behalf of your domain. Many organizations use multiple systems beyond their primary mail server to send emails such as marketing platforms, CRM tools, helpdesk software, and cloud services. If these sources are not properly identified and authenticated, DMARC could mistakenly block legitimate emails.   

How to Identify Legitimate Email Sources?

Internal Email Servers: 

• Microsoft 365 / Exchange Online 

• Google Workspace (Gmail) 

• On-premises Exchange servers 

Third-Party Services: 

• Marketing tools (e.g., Mailchimp, SendGrid, HubSpot) 

• CRM platforms (e.g., Salesforce, Zoho) 

• Helpdesk systems (e.g., Zendesk, Freshdesk) 

• Security platforms (e.g., Proofpoint, Barracuda, Mimecast) 

• Transactional mailers (e.g., Amazon SES, Postmark, Mandrill) 

Device or Application Senders: 

• Printers and scanners (for scan-to-email) 

• ERP or billing systems that generate invoices or alerts 

• Monitoring systems that send automated notifications 

Why it is Important?

• Ensures all legitimate senders are included in your SPF records and configured with DKIM signing. 

• Prevents legitimate business emails from being quarantined or rejected by DMARC. 

• Helps maintain smooth communication with customers, vendors, and internal teams. 

How DMARC Works?

DMARC acts as an additional layer of protection on top of SPF and DKIM, ensuring that only legitimate emails are delivered under your domain name. Here’s how it works in simple terms: 

Verification with SPF and DKIM 

• When an email is received, the mail server checks if it passes SPF (authorized sending server) or DKIM (valid digital signature). 

• At least one of these checks must align with the domain in the “From” address. 

Policy Enforcement 

Based on the DMARC record published in your domain’s DNS, the receiving server enforces one of the following policies: 

1. None: Monitor only, take no action.
2. Quarantine: Send suspicious emails to the spam/junk folder. 
3. Eject: Block and discard unauthenticated emails. 

Reporting & Feedback 

• DMARC generates two types of reports: 

1. Aggregate Reports (RUA): Summarized data showing which sources are sending email on behalf of your domain. 
2. Forensic Reports (RUF): Detailed information about specific emails that failed DMARC checks. 

These reports are sent to the addresses specified in the DMARC record, giving domain owners visibility into email activity.

The above diagram illustrates the step-by-step DMARC validation and enforcement process performed by the recipient’s mail server when an email is received: 

• Email Receipt: The recipient mail server receives the incoming email message. 

• SPF Validation: The server checks the sending IP address against the domain’s published SPF record to verify if the server is authorized to send mail for the domain. 

• DKIM Verification: Simultaneously, the server verifies the DKIM signature by retrieving the public key from DNS and ensuring the signature matches the email content. 

• DMARC Alignment Check: The server checks if either SPF or DKIM (or both) align with the sender’s domain as specified in the DMARC policy. 

• Policy Enforcement: Based on DMARC policy configured for that domain, the server takes action: 

• None: No special action, email is delivered as usual, but reports are generated. 

• Quarantine: The email is marked as suspicious and typically moved to the recipient’s spam/junkfolder. 

• Reject: The email is rejected outright and not delivered to the recipient. 

This process enhances domain protection by ensuring only authenticated emails pass through while suspicious or fraudulent messages are handled according to the sender’s specified policy, thereby reducing email spoofing and phishing risks. 

DMARC Record Syntax and Creation 

A DMARC policy is published in your domain’s DNS as a TXT record. This record tells receiving mail servers how to handle emails that fail SPF/DKIM checks and where to send reports. 

Example DMARC TXT Record:  

• Host/Name:  _dmarc 
• Value:    v=DMARC1; p=none; rua=mailto:dmarc- report@yourdomain.com; ruf=mailto:dmarc-report@yourdomain.com; fo=1; 

v=DMARC1- Protocol version 

• Required. Must always be the first tag. 

• Currently, the only valid value is DMARC1. 

p= none|quarantine|reject- Policy for handling unauthenticated emails 

• None: Monitor only, no action taken. 

• Quarantine: Send unauthenticated emails to spam/junk folder. 

• Reject: Block unauthenticated emails completely. 

rua= mailto:dmarc-agg@example.com- Aggregate reports 

• Optional but highly recommended. 

• Provides summary reports about all emails claiming to come from your domain. 

• Helps identify legitimate and unauthorized sending sources. 

ruf=mailto:dmarc-afr@example.com- Forensic reports 

• Optional. 

• Provides detailed reports for individual failed messages. 

• Can generate a large volume of data, so best used selectively. 

fo=1- Failure reporting option 

• Optional. 

• Tells mail receivers to generate reports if either SPF or DKIM fails. 

This figure shows the shows a DMARC TXT record as it appears in a DNS provider’s management console, highlighting the essential Host and Value fields. 

• Record Type: TXT 

• Host/Name: _dmarc (this indicates the record applies to your domain, for example, _dmarc.yourdomain.com) 
• Value:Text 

v=DMARC1; p=reject; pct=100; rua=mailto: dmarc-report@yourdomain.com; ruf=mailto:dmarc-report@yourdomain.com 

• v=DMARC1 specifies the version and that this is a DMARC record. 

• p=reject instructs receiving servers to reject all messages that fail DMARC checks.

• pct=100 applies this policy to 100% of emails. 

• rua and ruf define email addresses to receive aggregate and forensic reports respectively. 

• TTL: 1 Hour (the duration DNS servers cache the record before refreshing) 

It ensures that messages failing DMARC validation are blocked and that detailed reports are sent to the specified addresses, providing visibility and enforcement to protect your domain from email spoofing and phishing attempts. 

DMARC Setup 

Log in to your DNS provider 

• Sign in to the account that manages your domain’s DNS (GoDaddy, Cloudflare, Route 53, cPanel, etc.). 

• Open the DNS/Zone management area for the domain you want to protect. 

Create the DMARC TXT record 

• Choose Add new record (or Create record) – Type = TXT. 

• Host / Name: _dmarc 

• Value / TXT data: paste your DMARC policy string, 

for example:                 

v=DMARC1; p=none; rua=mailto:dmarc-agg@yourdomain.com; ruf=mailto:dmarc- .afr@yourdomain.com; pct=100; fo=1;   

• Make sure the value has no extra line breaks or stray quotes unless your registrar requires them. 

• rua and ruf may contain multiple addresses separated by commas. 

• TTL: set a sensible TTL (e.g., 3600 seconds / 1 hour) or leave default. 

• Save the record. 

Verify the DNS record 

Use either command-line tools or online checkers to confirm the TXT record was published correctly. 

Command-line examples 

• dig +short TXT _dmarc.example.com 

• nslookup -type=TXT _dmarc.example.com 

What to check 

• Ensure the record contains the v=DMARC1 tag indicating it is a valid DMARC record. 

• Confirm the p= tag is present with your desired policy (none, quarantine, reject). 

• Verify that no duplicate DMARC records exist for your domain, which can cause conflicts. 

• Check that the rua (aggregate reports) email addresses are correct and able to receive mail. 

Online Validation Tools:

For additional syntax validation and parsing checks, use DMARC analyzers and online checkers such as: 

• MXToolbox DMARC Lookup 

• dmarcian 

• DMARC Analyzer 

These tools provide detailed feedback and help ensure your DMARC record is correctly published and effective. 

Monitor reports & tune policy 

• Monitor aggregate (RUA) reports to see which systems are sending on your behalf. 

• Investigate any unexpected senders; update SPF/DKIM to include legitimate sources. 

• Move policy gradually: p=none, p=quarantine (partial or pct-based), p=reject once you’re confident. 
• Keep refining SPF/DKIM alignments and any third-party configurations. 

Example DMARC records (common cases) 

• Monitoring (start here): 

v=DMARC1; p=none; rua=mailto:dmarc-agg@yourdomain.com; pct=100; 

• Quarantine (staged enforcement): 

v=DMARC1; p=quarantine; rua=mailto:dmarc-agg@yourdomain.com; pct=25; fo=1; 

• Full enforcement (when ready): 

v=DMARC1; p=reject; rua=mailto:dmarc-agg@yourdomain.com; pct=1 

Choosing the Right DMARC Policy 

One of the most important decisions in implementing DMARC is selecting the correct policy (p=). This policy tells receiving mail servers what to do with emails that fail SPF and DKIM checks. 

Policy Options: 

p=none (Monitor Mode) 

• No action is taken on failing messages. 

• All emails are delivered as usual. 

• Aggregate (RUA) and forensic (RUF) reports are still generated, giving visibility into who is sending on your behalf. 

• Best used as the starting point to gather data without impacting mail flow. 

p=quarantine (Cautious Enforcement) 

• Emails that fail DMARC are delivered to the recipient’s spam/junk folder instead of the inbox. 

• This reduces the risk of phishing emails reaching users while still allowing delivery. 

• Useful as an intermediate step after you’ve validated legitimate senders. 

p=reject (Strict Enforcement) 

• Emails that fail DMARC are blocked and not delivered. 

• Provides the strongest protection against spoofing and phishing. 

• Should be applied only after thorough monitoring and validation of all legitimate sources. 

Best Practice: Start Light, Then Enforce 

• Begin with p=none for a monitoring-only phase. This allows you to review DMARC reports and identify all authorized email senders. 

• Once confident that SPF and DKIM are properly configured, transition to quarantine (possibly starting with a lower percentage using pct=). 

• Finally, move to reject for full enforcement and maximum protection once all legitimate sources are aligned.

DMARC Reporting and Monitoring 

One of DMARC’s greatest strengths is its reporting capability, which gives domain owners deep visibility into how their domain is being used across the email ecosystem. Analyzing these reports is essential for monitoring email authentication and identifying potential threats. 

Types of DMARC Reports 

Aggregate Reports (RUA): 

• Sent in XML format, usually once per day by major email providers. 

• Summarized data showing how many emails passed or failed SPF and DKIM checks. 

Forensic Reports (RUF): 

• Sent in real time when individual messages fail DMARC checks. 

• Contain detailed information about the failed email (headers, sending source, etc.). 

• Useful for investigating attacks, though they can generate a high volume of data. 

Why Monitoring Reports Matters 

• Detect unauthorized email activity and block spoofers. 

• Validate that legitimate senders are properly aligned with SPF/DKIM. 

• Fine-tune your DMARC policy (moving from none → quarantine → reject) with confidence. 

• Improve overall email deliverability and domain reputation. 

Tools and Services for DMARC Report Management 

Since raw DMARC reports are often in XML and hard to read, many organizations rely on reporting tools to visualize and interpret the data. Common solutions include: 

• dmarcian – User-friendly dashboards for monitoring reports. 

• DMARC Analyzer – Detailed analysis and alerts. 

• Agari (Fortra) – Enterprise-grade email security insights. 

• Valimail Monitor – Free and paid tools for DMARC compliance tracking. 

• Postmark DMARC Digests – Easy-to-read email digests of DMARC data. 

Troubleshooting and Best Practices 

Implementing DMARC can sometimes be challenging, especially when multiple third-party services send email on behalf of your domain. To ensure a smooth rollout and effective enforcement, follow these best practices:  Validate Your Record 

• Use online DMARC checkers (such as MXToolbox, DMARCian, or DMARC Analyzer) to confirm that your TXT record is valid and correctly published. 

• Ensure the record is placed at the correct host: _dmarc.yourdomain.com. 

Monitor Before Enforcing 

• Start with p=none to gather data without impacting mail flow. 

• Review aggregate reports to identify all legitimate senders before moving to stricter policies. 

Adjust Gradually 

• Move from none, quarantine, reject in stages. 

• Update SPF and DKIM records for all authorized senders before tightening enforcement. 

Review Reports Regularly 

• Look for unauthorized sources trying to spoof your domain. 

• Verify that legitimate providers (e.g., Microsoft 365, Google Workspace, Salesforce, etc.) are passing SPF/DKIM alignment. 

 Educate Teams 

• Make sure IT, marketing, and other teams know about DMARC. 

• Stricter enforcement can impact newsletters, bulk emails, or third-party tools if not configured correctly. 

Benefits of Adopting DMARC 

Implementing DMARC is one of the most effective steps organizations can take to strengthen email security. By adopting DMARC, you gain: 

• Protection Against Spoofing & Phishing: Prevents attackers from sending emails that impersonate your domain. 

• Improved Email Deliverability: Builds trust with mail providers, reducing the chance of legitimate messages being marked as spam. 

• Greater Visibility: DMARC reports give clear insight into who is sending emails on behalf of your domain. 

• Enhanced Brand Reputation: Protects customers, partners, and employees from fraudulent emails that could harm your brand. 

• Stronger Security Posture: Complements SPF and DKIM, creating a layered defense strategy against email-based threats. 

Conclusion 

Adopting DMARC is a crucial step toward safeguarding your organization’s email ecosystem. It not only prevents domain spoofing and phishing but also enhances your domain’s reputation and ensures that legitimate emails are delivered reliably.  The real power of DMARC lies in its visibility and control by analyzing reports, you gain valuable insights into who is sending emails on behalf of your domain. Starting with a monitoring policy (p=none) and gradually progressing to stricter policies (quarantine or reject) allows you to balance security with business continuity.  To maximize email security, organizations should treat DMARC as an ongoing process. Regular monitoring, policy adjustments, and continuous education of teams are essential to stay ahead of evolving threats.  By implementing and actively managing DMARC, you protect your brand, build trust with recipients, and contribute to a safer global email environment.