DMARC record: Difference between revisions
mNo edit summary |
|||
Line 58: | Line 58: | ||
A DMARC policy allows a sender to indicate that its emails are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes. | A DMARC policy allows a sender to indicate that its emails are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes. | ||
== | |||
== Create DMARC and Verify Existence and Propigation == | |||
===Create DMARC DNS entry=== | |||
Create a record for your domain DNS of type TXT and with name dmarc. Here is a sample using intel.net as a domain. | |||
Type: TXT | |||
Name: _dmarc | |||
Value: v=DMARC1; p=quarantine; fo=1; rua=mailto:dmarc_agg@intel.net;ruf=mailto:dmarc_forensic@intel.net;pct=100 | |||
DMARC Specification: The rua (aggregate reports) and ruf (forensic reports) fields specify where receiving mail servers send DMARC reports. The email addresses listed don’t need to belong to the same domain as the DMARC record. he DMARC standard allows any valid email address, as long as the receiving domain accepts the reports. While not required, some prefer report addresses to match the domain for clarity or organizational consistency. However, this is a convention, not a rule. | |||
Here is how the Value breaks down: | |||
* v=DMARC1: Specifies the DMARC version, required for validity. | |||
* p=quarantine: Sets the policy to "quarantine," instructing receiving servers to treat unauthenticated emails (those failing SPF or DKIM) as suspicious (e.g., send to spam/junk). This is a functional policy, stronger than p=none, showing you’re actively managing authentication. | |||
* fo=1: Forensic reporting option set to "1" means reports are sent if all authentication mechanisms fail. This doesn’t affect compliance perception but controls report triggers. | |||
* rua=mailto:dmarc_agg@intel.net: Specifies aggregate report destination. Even if routed to null, including it satisfies DMARC syntax and shows monitoring intent. | |||
* ruf=mailto:dmarc_forensic@intel.net: Specifies forensic report destination. Similarly, null-routing doesn’t impact compliance; it’s optional but enhances the record’s completeness. | |||
* pct=100: Applies the policy to 100% of emails, reinforcing that your domain fully enforces DMARC. | |||
===Check domain for existence of DMARC record=== | ===Check domain for existence of DMARC record=== | ||
If the domain in question is, for example, intel.net type the following command: | If the domain in question is, for example, intel.net type the following command: |
Revision as of 13:30, 24 March 2025
Domain-based Message Authentication, Reporting, and Conformance aka DMARC. DMARC is an email authentication protocol that helps prevent spoofing by verifying sender domains.
DMARC is a system that adds some rules for DKIM and SPF, so remote servers have a better idea of what your intention is for messages that fail those 2 systems. DMARC requires both the SPF and DKIM to be present in order to work.
Without a DMARC record for your email domain, your emails may not reach their intended recipients. Some email systems use anti-spam and authentication mechanisms that can reject or flag messages from domains lacking a DMARC record. For example, Google’s Gmail may mark emails as spam or reject them if they fail DMARC checks, especially for bulk senders or when spoofing is suspected. Adding a proper DMARC record to your domain’s DNS configuration helps verify your emails as legitimate, increasing the chances they’ll be delivered successfully rather than being marked as spam or rejected outright.
When you add a DMARC policy to your domain, you choose to inform the recipient that your emails are protected by DKIM and/or SPF records and what to do if your DMARC policy fails alignment with those records.
SPF - Sender Policy Framework
Anything that contains the word "framework" is typically crap. Here's more crap we're stuck with.
SPF allows administrators to specify which hosts are allowed to send email from a given domain by creating a specific DNS SPF record in the public DNS.
Mail Exchanger (MX records) then uses the DNS to check that mail from a given domain is being sent by a host sanctioned by that domain's administrator.
You set up SPF in your domain name at the DNS server. Create a TXT entry in the DNS records of your domain.
Here is an example of a most simple SPF record
v=spf1 a -all
Here is a more complex example
v=spf1 a include:_spf.crap.com ip4:123.45.67.8 -all
Only "include" existing SPF records. If there is no SPF for crap.com then don't do it like the example above.
Often an SPF record can be condensed down to something like v=spf1 ip4:x.x.x.x -all if there is only one outgoing mail server.
v=spf1 ip4:123.45.67.8 -all
Without the "a" then it will deny. This is how you specify a server that does not send mail.
SPF's purpose is to publish a list of outgoing mail servers. Any servers that do not deliver mail to the world, such as web servers or incoming-only mail servers, should not be listed.
If the IP address of your outgoing server is covered by an a, ip4, or other mechanism, it is not necessary to reference that server again using the mx mechanism in the SPF text DNS entry. Specifying mx:mailserver.example.com is generally incorrect.
Based on my current understanding, if you have 1 mail server which both sends and receives mail for many domains:
v=spf1 a include:_mailservername.com ip4:123.45.67.8 -all
The name of the mail server and the IP address of the mail server should be used.
SPF Testing Utility Online - http://tools.bevhost.com/spf/
Again, for domains that send no email you should do this:
v=spf1 -all
DKIM - Domain Key Identified Mail
DKIM uses a key pair, consisting of a public key and a private key. Again more confusing and overly complicated crap!
One key, the "Private Key", is kept safe by the email author. The other key, a "Public Key" permits anyone to verify that a signature made with the corresponding Private Key is valid. DKIM uses DNS to publish the Public Keys, so that any party that wants to validate a signature can easily find the public key.
In your mail server outbound messages will need to pass through a filter that will generate the corresponding signature and store it in an email header.
DMARC - Domain-based Message Authentication, Reporting and Conformance
A DMARC policy allows a sender to indicate that its emails are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes.
Create DMARC and Verify Existence and Propigation
Create DMARC DNS entry
Create a record for your domain DNS of type TXT and with name dmarc. Here is a sample using intel.net as a domain.
Type: TXT Name: _dmarc Value: v=DMARC1; p=quarantine; fo=1; rua=mailto:dmarc_agg@intel.net;ruf=mailto:dmarc_forensic@intel.net;pct=100
DMARC Specification: The rua (aggregate reports) and ruf (forensic reports) fields specify where receiving mail servers send DMARC reports. The email addresses listed don’t need to belong to the same domain as the DMARC record. he DMARC standard allows any valid email address, as long as the receiving domain accepts the reports. While not required, some prefer report addresses to match the domain for clarity or organizational consistency. However, this is a convention, not a rule.
Here is how the Value breaks down:
- v=DMARC1: Specifies the DMARC version, required for validity.
- p=quarantine: Sets the policy to "quarantine," instructing receiving servers to treat unauthenticated emails (those failing SPF or DKIM) as suspicious (e.g., send to spam/junk). This is a functional policy, stronger than p=none, showing you’re actively managing authentication.
- fo=1: Forensic reporting option set to "1" means reports are sent if all authentication mechanisms fail. This doesn’t affect compliance perception but controls report triggers.
- rua=mailto:dmarc_agg@intel.net: Specifies aggregate report destination. Even if routed to null, including it satisfies DMARC syntax and shows monitoring intent.
- ruf=mailto:dmarc_forensic@intel.net: Specifies forensic report destination. Similarly, null-routing doesn’t impact compliance; it’s optional but enhances the record’s completeness.
- pct=100: Applies the policy to 100% of emails, reinforcing that your domain fully enforces DMARC.
Check domain for existence of DMARC record
If the domain in question is, for example, intel.net type the following command:
dig TXT _dmarc.intel.net
Output Status: NXDOMAIN (no such domain/record) or NOERROR (query successful). ANSWER Section: Appears with the DMARC TXT record, e.g., "v=DMARC1; p=quarantine; ...". The string starts with v=DMARC1 (the version) followed by policy tags like p= (policy: none, quarantine, or reject), rua= (aggregate report email), etc. TTL: A time-to-live value (e.g., 3600 seconds) indicates how long the record is cached.
references
- http://techarena51.com/index.php/what-is-dmarc-and-how-you-can-add-it/
- http://www.openspf.org/FAQ/Common_mistakes
To add a DMARC record, go to your domain's DNS Management,