DMARC: the guardian of email authentication
DMARC (Domain-based Message Authentication, Reporting & Conformance) is the protocol that completes the email authentication trio. While SPF and DKIM are authentication mechanisms, DMARC is a policy: it tells receiving servers what to do when an email fails authentication. Without DMARC, an email that fails SPF or DKIM might still be delivered — the decision is left entirely to the receiving server. With DMARC, the domain owner takes back control.
DMARC also verifies domain alignment: it checks that the domain in the From header (the one the user sees) matches the domain authenticated by SPF or DKIM. This is crucial because an attacker could configure SPF and DKIM for their own domain, but send emails with your domain in the From field. DMARC alignment prevents this scenario, closing the gap between technical authentication and visible identity.
The three DMARC policies
DMARC implementation should always be gradual. Starting directly with p=reject is risky: you might block legitimate emails sent by services you have not yet authenticated with SPF/DKIM. The recommended strategy is: start with p=none to collect data (typically 2-4 weeks), analyze the reports to identify all legitimate email sources, configure SPF and DKIM for each one, then move to p=quarantine with a low pct (25-50%), gradually increase it, and finally activate p=reject.
DMARC reports: the visibility you were missing
One of the most underrated advantages of DMARC is aggregate reports (rua). Every server that receives email from your domain sends daily reports in XML format showing: how many emails were received, from which IPs, whether they passed or failed SPF/DKIM, and what action was applied. These reports are a goldmine of information: they reveal services sending email on your behalf that you may have forgotten about, spoofing attempts against your domain, and configuration issues.
To analyze DMARC reports (which are in raw XML and difficult to read), there are dedicated services that aggregate them into readable dashboards. Alternatively, you can start with a manual review of the most significant reports. The key metric to monitor is the ratio of authenticated to unauthenticated emails: if you see many legitimate emails failing, you need to update SPF or DKIM before tightening the policy.
Verify and generate your DMARC record
Our DMARC Lookup analyzes your domain's DMARC record, showing the policy, alignment parameters, report addresses, and any syntax errors. If you do not have a DMARC record yet, use the DMARC Generator to create a customized one with the correct options. The tool generates the TXT record ready to be inserted into DNS.
Remember that the DMARC record must be inserted as a TXT record on _dmarc.yourdomain.com. A common mistake is inserting it at the domain root or with a wrong hostname. Also verify that SPF and DKIM are properly configured before activating DMARC: without at least one of the two authentication protocols, DMARC has no basis to operate on. Use SPF Lookup and DKIM Lookup for a complete verification.
Finally, pay attention to the subdomain policy (sp=). If not specified, subdomains inherit the parent domain's policy. But if your subdomains do not send email, it is good practice to set sp=reject to prevent them from being used for spoofing, even if the main domain's policy is still in monitoring mode with p=none.