DMARC record

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.

What DMARC does for Domain Owners

DMARC (Domain-based Message Authentication, Reporting and Conformance) is an email authentication protocol used by domain owners to protect their domains from unauthorized uses, such as spoofing attacks. Publishing DMARC Record will let MBPs (Mailbox Providers) such as Google, Verizon & Comcast define rules with reporting and handling any unauthorized use of access based on your stated DMARC policy.

On initial implementation many mail server administrators moaned that yet another complex configuration was necessary for every domain that was hosted on the mail server. Little documentation existed at the time and DMARC records some of which were initially incorrect causing mail delivery problems as an invalid DMARC record is as bad as none at all. DMARC is open and free for anyone to use, allowing you to secure your domain’s emails and gain control of your email delivery. Setup is simple and now that plenty of documentation exists mail server administrators will find it is no trouble at all.

DMARC allows you to see whether emails sent using your domain are properly authenticated using SPF and DKIM. This allows you to identify and fix any authentication issues that can affect the delivery reliability of your emails. Preventing spoofed emails from reaching users can lower spam complaints and protect your domain‘s reputation. Your domain name should only be used by those whom you authorize, not by any 3rd party trying to leverage your domain name for their benefit without your permission.

Mail servers that support DMARC will also generate reports on sending activity for your domain. The reports are XML files that are emailed to the email address specified in your DMARC record. The reports contain the sending source (domain/IP) along with whether the message passed or failed SPF and DKIM. This is one of the best aspects of DMARC. Not only does it allow you to control email security for your domain, it also gives you deep visibility into who is sending on your behalf AND if they are signing with DKIM or passing SPF.

DMARC Build

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,

• https://help.directadmin.com/item.php?id=596