DMARCReport Glossary
DMARC
Domain-based Message Authentication, Reporting, and Conformance.
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It’s an email authentication protocol that allows domain owners to set rules in a way that only approved senders can send emails on their behalf.
DMARC record
This is a TXT entry in your domain’s DNS that holds your DMARC rules. It tells email servers what to do with emails that fail checks. Without it, you can’t enforce DMARC.
The record includes tags for policy, reporting, and other configurations; hence, it must be correctly published in your DNS for DMARC to work.
A common DMARC record starts with v=DMARC1; followed by tags like p= and rua=.
DMARC policy
The DMARC policy is the action you choose for failed emails: none, quarantine, or reject. “None” is just monitoring, “quarantine” usually sends it to spam, and “reject” blocks it. The policy is set inside your DMARC record.
Choosing the right policy depends on how prepared your email setup is. Most organizations start with “none” before moving to stricter policies. Setting a proper policy improves domain security and email deliverability.
p=none
This means your DMARC policy is set to “none.” It’s also called the ‘’monitoring’’ policy because no action is taken on illegitimate emails when this policy is applied. It’s essentially only to figure out the current situation of email traffic.
It’s the safest starting point when you’re new to DMARC, and reports will show which sources are failing without affecting delivery. It’s suggested to use this to gather enough data before applying stronger policies.
p=quarantine
This policy tells email servers to send failed emails to the spam or junk folder. It keeps them away from the inbox but doesn’t block them entirely, acting as a good middle ground. The p=quarantine policy ultimately helps reduce phishing attempts while avoiding false positives. But before applying, ensure your authorized sources pass DMARC checks.
p=reject
This policy blocks emails that fail DMARC checks from being delivered at all. It’s the strongest setting and stops spoofing effectively. Use it when you’re sure your setup is correct. It’s best to switch to this after thorough monitoring and testing.
The p=reject policy provides the highest level of email domain protection, and hence can significantly reduce impersonation-based attacks.
rua
rua is a DMARC tag that lets domain owners specify where the sending mail servers should send the aggregate reports for emails that didn’t pass the DMARC check and weren’t placed in the inbox.
Example: rua=mailto:dmarc-reports@yourdomain.com.
These reports help identify legitimate services that may need alignment. Always use a monitored mailbox to receive these reports for analysis. Also, you can add multiple email addresses by separating them with commas.
ruf
ruf is the tag for forensic (or failure) reports. These contain detailed info about individual failed emails. Not all providers send these reports.
Forensic reports can include sensitive information like message headers. They are useful for investigating phishing attempts or spoofing sources. Since they contain personal data, handle them according to privacy laws.
DMARC aggregate report
This is a summary of how your domain’s emails performed against DMARC over a certain period. It helps you know how many emails passed or failed, which ultimately aids in spotting the problems. They show sending sources, pass/fail rates, and alignment status.
DMARC forensic report
This report gives detailed data about specific failed emails. It can include the source IP, sending domain, and headers. You don’t always get them because not all servers send them. These reports are triggered immediately when a failure occurs, providing deeper insight compared to aggregate reports. Due to privacy concerns, some providers do not send forensic reports at all.
DMARC alignment
Alignment means the “From” address matches the domain used in SPF or DKIM. You can choose relaxed (just the main domain matches) or strict (exact match). Alignment is a key DMARC rule. It ensures that the domain shown to users is the same one authenticated by SPF or DKIM.
Without proper alignment, even if SPF or DKIM passes, DMARC can still fail.
This rule helps prevent attackers from using lookalike domains to trick recipients.
SPF alignment
This checks if the domain in the SPF pass result matches the “From” domain. If it does, SPF is considered aligned. SPF alignment is a must for DMARC to pass via SPF. Relaxed alignment allows subdomains, while strict requires an exact match.
Maintaining SPF alignment helps email providers trust your messages. It’s vital when using multiple third-party email services.
DKIM alignment
This checks if the domain in the DKIM signature matches the “From” domain. If it does, DKIM is considered aligned. It’s important for DMARC to pass via DKIM. Like SPF, alignment can be relaxed or strict depending on your policy.
DKIM alignment adds another layer of security against domain spoofing. It’s widely preferred because DKIM verification remains intact during forwarding.
DMARC relaxed alignment
In relaxed alignment, the main domain needs to match, but subdomains are okay. Example: “mail.example.com” aligns with “example.com.” It’s less strict.
This option is often used when multiple subdomains send email on behalf of the main domain. Relaxed alignment is easier to implement and reduces email delivery issues. However, it offers slightly less protection compared to strict alignment.
DMARC strict alignment
Here, the “From” domain must match exactly. “mail.example.com” would NOT align with “example.com.” It’s stricter and better for security. Strict alignment is recommended for organizations with tight security needs as it minimizes the risk of attackers exploiting subdomains for spoofing.
Before enabling, make sure all legitimate sources use the exact domain.
DMARC rua tag
This is the part of your DMARC record that says where to send aggregate reports. You can have multiple email addresses listed. Example: rua=mailto:report1@domain.com,mailto:report2@domain.com.
Aggregate reports give an overview of email authentication results over time. They help identify unauthorized sending sources or misconfigured services. You should always ensure the email addresses are valid and can handle XML report files.
DMARC ruf tag
This tells servers where to send forensic reports. It’s written like ruf=mailto:reports@domain.com. It only works if the sending server supports it. Forensic reports provide detailed information about individual failed messages. They can be useful for investigating phishing attempts or spoofing cases. Because they may include personal data, handle them securely and with privacy compliance.
DMARC pct tag
This tag sets the percentage of emails DMARC should apply to. pct=50 means only half of your emails follow the policy. This tag is quite helpful for testing. It allows gradual enforcement of DMARC without risking full email rejection.
Starting with a lower percentage helps identify issues before going 100%. Once confident, increase the pct value until you reach complete enforcement.
DMARC fo tag
This controls when forensic reports are sent. For example, fo=1 means send a report if SPF or DKIM fail. There are different numbers for different fail rules. Options include fo=0 (send if both fail) or fo=d (send on DKIM failure only).
Choosing the right value helps balance security insights and report volume. Security teams commonly use it to monitor specific types of failures.
DMARC version tag (v=DMARC1)
Every DMARC record starts with v=DMARC1. It tells the server that this TXT record is for DMARC. Without it, the record won’t work. This tag is mandatory and always comes first in the DMARC record syntax.
Currently, DMARC1 is the only supported version globally. If this is missing or incorrect, the entire DMARC policy will be ignored.
DMARC adkim tag
This sets DKIM alignment mode to relaxed or strict. adkim=s means strict, adkim=r means relaxed. It’s part of your DMARC record. Strict alignment is more secure but requires exact domain matching. Relaxed alignment is easier to implement when multiple subdomains are involved. Configuring adkim properly ensures DKIM passes under your desired policy.
DMARC aspf tag
This sets SPF alignment mode to relaxed or strict. aspf=s means strict, aspf=r means relaxed. Just like adkim, strict mode gives stronger security but is harder to maintain. Relaxed mode is commonly used during the initial stages of DMARC deployment. Proper aspf configuration helps prevent domain spoofing effectively.
DMARC report parser
A tool that takes raw DMARC reports and turns them into easy-to-read charts or tables. Without one, reports are in XML and hard to read. Parsers make it simple to identify pass/fail trends and unauthorized senders.
They also save time by automating data analysis across multiple reports. Many organizations use cloud-based parsers for centralized monitoring.
DMARC fail
This means an email didn’t pass DMARC checks. It failed both SPF and DKIM alignment. The server will follow your DMARC policy for it. Failing emails are usually signs of spoofing or misconfigured systems.
Regularly reviewing DMARC fail reports helps detect security gaps early. A high failure rate may necessitate updates to SPF, DKIM, or source sending.
DMARC pass
This means the email passed DMARC checks. It aligned with SPF or DKIM (or both). Passing means the email is more trusted. Passing improves your domain’s reputation with email providers, ensuring that legitimate messages reach inboxes instead of being marked as spam.
Maintaining consistent pass rates is crucial for strong deliverability.
DMARC monitor mode
This is when you set p=none to just monitor results without blocking anything. It’s the first step in a DMARC rollout. It essentially lets you gather data safely.
Monitor mode helps identify legitimate senders before enforcement. Reports collected during this phase guide future policy decisions. Most organizations stay in monitor mode for a few weeks before tightening controls.
DMARC enforcement
This is when you set p=quarantine or p=reject so failed emails are acted on. Enforcement protects you from spoofing. You usually reach this stage after testing. It ensures fraudulent emails don’t reach your users’ inboxes. Before enforcement, confirm all authorized senders are DMARC-compliant. Skipping this step can lead to email delivery disruptions for legitimate sources.
DMARC subdomain policy (sp=)
This tag lets you set a separate policy for subdomains. Example: sp=reject applies reject mode to all subdomains. It’s optional.
Using sp= helps maintain different security levels for root domains vs subdomains. It’s particularly useful when subdomains are managed by different teams. If not defined, subdomains inherit the main domain’s policy by default.
DMARC report format
Aggregate reports are in XML, and forensic reports may be in text or XML. They’re sent to the addresses in your rua or ruf tags. You need a tool to read them easily.
The XML structure contains detailed authentication results for each source. Without a parser, interpreting these reports can be time-consuming. Most organizations rely on automated tools for accuracy and speed.
DMARC lookup
This is when a server checks your DMARC record by looking it up in DNS. It happens whenever an email using your domain is received. You can also do it with online tools.
A successful lookup ensures the recipient server knows your DMARC rules. Errors in DNS or syntax can cause lookups to fail, impacting security. Manual lookups are useful for troubleshooting DMARC issues quickly.
DMARC record example’
Example:
v=DMARC1; p=quarantine; rua=mailto:reports@yourdomain.com; ruf=mailto:forensic@yourdomain.com; adkim=s; aspf=sYou have to replace details with your own.
This sample includes tags for policy, reporting, and alignment. Always test your record using a DMARC checker before publishing. Errors in syntax can make the record invalid and DMARC ineffective.
DMARC checker
DMARC checker is an online tool that checks your DMARC record for errors. It tells you if it’s valid and shows your policy settings. It’s good for testing changes.
Checkers help detect missing tags or incorrect email addresses. They also confirm that your record is visible in DNS and functioning. Running checks regularly prevents misconfiguration-related delivery issues.
DMARC record generator
It’s a tool that creates a DMARC record for you based on your choices. You have to simply select your policy, configure email reporting, and set alignment settings. It writes the record so you can paste it into DNS.
DMARC report analyzer
It’s the same as a parser; it reads your DMARC reports and shows trends, pass/fail rates, and sources, ultimately helping you spot suspicious senders.
Analyzers often include dashboards for visual reporting and filtering. They can track historical trends to measure the success of your DMARC policy. Some advanced analyzers integrate alerts for unusual activity.
DMARC domain alignment
This is the main DMARC rule where “From” must match SPF or DKIM domains. Without alignment, even SPF/DKIM passes won’t count for DMARC. It’s what makes DMARC stronger than using SPF/DKIM alone.
DMARC troubleshooting
This means finding out why emails are failing DMARC. It could be a missing include, wrong alignment, or sending from unapproved servers. You fix it by updating your SPF/DKIM or DMARC record.
DMARC DNS TXT record
This is the actual DNS entry that holds your DMARC settings. You add it to your domain host’s DNS manager. Without this TXT record, DMARC isn’t active.
It must be published in the correct DNS zone for your domain. Any syntax error in this record can disable your DMARC policy. Always confirm DNS propagation after publishing to ensure it’s live.
