Help Center
Try for Free Login

Deliverability

DMARC Security

What is DMARC?

Domain-based Message Authentication, Reporting & Conformance or DMARC is an additional layer of security you can enable for your domain in a few different varying degrees of severity. For anyone who is brand new to email, this is typically not something that we recommend setting up, but as a business matures and is sending more and more emails, this is definitely something to consider as it will ensure that only you can send emails from your domain.

In short, DMARC is essentially a Pass/Fail checker to see if an email sent from your name@domain.com is meeting the current SPF/DKIM checks, and will determine how inboxes handle any emails that fail this check. This can vary from “Do Nothing” to “Reject this email”, with the later of these two options being where most problems can arise. 

In order for DMARC to work, and to work with Drip, you must have a Custom Sending Domain setup and properly configured for your domain, as when you first create your Drip account you will be sending unauthenticated email. We have an article with additional information on Custom Sending domains and steps on how to set that up which can be found here.

We do not provide instructions on how to setup a DMARC record as this is typically something that you will want to make sure to troubleshoot and work with your Webmaster or IT team to implement in stages. With that being said, Drip does fully integrate and work with DMARC security provided you setup your Custom Sending Domain beforehand.

 

Why is DMARC Important?

Spammers and phishers are attacking user accounts more frequently these days. By gaining access to passwords, financial records, and other sensitive information, these malicious actors can easily compromise victims’ financial security and safety.

Email is a particularly common target for spoofing. Something easy like inserting the logo of a major brand into an email or making an email address look similar to a major brand can trick people into believing they’ve been sent something legitimate.

DMARC works to thwart these kinds of attacks at scale. Realistically, email providers don’t have the bandwidth to inspect every email that passes through their servers to determine which ones to allow and which ones are security risks. 

DMARC, when combined with SPF & DKIM, becomes a suite of powerful security tools for better email security.

Many of the most popular email providers use DMARC, including Yahoo, Gmail, and Outlook to help protect people from being victimized via email by malicious actors.

 

Benefits of DMARC

DMARC records protect your company, your domain, and the people you send to. It can also provide insight into who’s using your email domain to send unauthorized emails. Over time, it will make your email sending more secure while also increasing your company’s sender reputation. 

 

Deploying DMARC

Deploy DMARC gradually by completing this checklist:

  • Deploy SPF and DKIM.
  • Make sure your mailers are aligned with the appropriate identifiers.
  • Publish a DMARC record with the “none” flag to trigger data reports.
  • Analyze the report and make any needed modifications.
  • Modify DMARC policy flags to “quarantine” or “reject” as you gain a better understanding of what is best for your company. Use pct= to set a percentage on policy flags to test their impact on delivery.

Deploying DMARC isn’t as easy as simply flipping a switch, but using this checklist can help everyone involved ease into a full deployment over time.

How can I check if my domain is using DMARC?

If you want to check if a domain is using DMARC, you can use a free DMARC record checker online. Type in the URL of the domain you wish to check and it’ll tell you if a DMARC record is detected for that domain.

Conversely, DMARC records can be checked from the command line of a terminal window when formatted like this: 

dig txt dmarc.getdrip.com

 

DMARC Tips & Tricks

How does DMARC email authentication work?

DMARC fits into existing inbound email authentication processes, helping receivers determine if a message aligns with what it has on record about a sender.

If there’s a misalignment, the receiving server can check the DMARC record for guidance on how to handle the unaligned message. Here’s an example of this flow for a common setup:

  1. An email is sent.
  2. The sending server inserts a DKIM header.
  3. The sending server sends the email to the receiver.
  4. The email passes through standard validation tests regarding IP, rate limits, reputation, etc.
  5. The receiving server retrieves verified DKIM domains based on the header, an “envelope from” via SPF, and applies the configured DMARC policies of that domain. It will either pass the email along, quarantine it, or reject it 
  6. The ultimate action taken for the email is sent to the sender’s server via a report. 

What are the components of DMARC?

To understand DMARC, it’s important to understand the fundamentals of SPF, DKIM, and Domain Name System (DNS) records:

SPF

SPF helps detect misalignment by reviewing an email’s listed return-path address. When an email can’t be sent to its intended recipient after a delay or after multiple tries, a failure notification is usually sent to the return-path address.

How SPF Works

Domain owners can decide which mail servers their domain is allowed to send from when they set up their SPF protocols.

  1. SPF information is entered into a TXT record. This defines the mail servers authorized to send email for a domain.
  2. An inbound mail server receives a new email. It checks the written rules for the domain of the return-path email address. The inbound server compares the IP address of the mail sender with the domains and/or IP addresses defined in the SPF record.
  3. The receiving server uses the rules specified in the sender’s SPF record and determines whether it should accept, reject, or flag the message.

DKIM

DKIM is an email authentication technique that ensures email content is kept safe from tampering by using an encryption signature inserted into the header of an email message. When a receiving server validates this DKIM signature, it can confirm that the email and attachments have not been modified.

How DKIM validates:

  1. The domain owner publishes a unique cryptographic key, formatted as a TXT record within the domain’s DNS record.
  2. When a message is sent by an outbound server, it generates and attaches a unique DKIM signature to the header.
  3. Inbound servers receive an encrypted hash of the message body.
  4. The receiving server first locates the DKIM public key that’s referenced in the DKIM signature and stored in the DNS records.
  5. The key is used to decrypt the hash and then generate a new hash of the message body, comparing it to the original included by the sender.
  6. If the two hashes match, they can validate that the message wasn’t altered in transit.

IP address record

The type of DNS record that points domains to an IP address is called an address record or “A” record.

 

CNAME record

A CNAME (Canonical Name) record is a type of DNS record that maps an alias name to a canonical domain name. CNAME records usually map a subdomain like “www” or “mailto:” to the domain that hosts that subdomain’s content.

 

DMARC record

Along with your DNS records, your DMARC record is published and available for anyone online to view. It’s made up of several pieces of information and is stored as a TXT record:

v=DMARC1

The receiving server looks for the above identifier when it scans a DNS record for the domain sending the message. If this tag doesn’t exist, no DMARC check is run.

p=reject, p=none, p=quarantine

Domain holders can select from 3 policy options (set by p=) to advise the receiving server on what to do with mail that doesn’t pass SPF and DKIM but claims to originate from your domain:

  • p=none: tells the receiver to perform no actions against unauthenticated mail, but instead to send email reports to the mailto: address listed in the DMARC record.
  • p=quarantine: tells the receiver to quarantine unqualified messages, which usually results in them being marked as spam/junk by email providers.
  • p=reject: tells the receiver to deny unqualified mail. Only verified email is permitted to pass through to inboxes. Mail that is rejected is blocked from delivery.

rua=mailto:

This section tells the receiving server where it can send high-level aggregate DMARC reports.

ruf=mailto:

Similar to rua=mailto:, ruf=mailto: tells the receiving server where it can send detailed incident reports about DMARC failures. These reports are sent to the administrator of the domain.

fo=

This section displays one of several values related to detailed reporting options:

  • 0 generates reports when all authentication mechanisms fail to pass an email
  • 1 generates reports when any mechanism fails
  • d generates reports if DKIM signatures fail to verify
  • s generates reports if SPF fails

sp=

When this is included, it tells the receiving server whether it should apply DMARC policies to subdomains.

adkim=

When this is included, it sets the DKIM alignment to either s (strict) or r (relaxed). Strict means the DKIM portion will pass only when the d= field in the DKIM signature matches the from address exactly. The relaxed setting allows messages to pass the DKIM portion if the DKIM d= field matches the root domain of the sender’s address, and is the default behavior if there is no adkim= parameter in the DMARC record.

ri=

This value sets the interval for the preferred frequency of aggregate reports sent.

aspf=

Another optional value, aspf= sets the strictness required for SPF alignment to either s (strict) or r (relaxed). Strict means that SPF will align only when the SPF “from” matches the header “from” exactly. The relaxed setting allows SPF to align if the Mail From domain and header from domain share the same organizational domain.

pct=

This optional value allows a domain owner to set a percentage on how many emails are sent with a particular policy. This is useful when first implementing DMARC to measure the difference in email delivery success for emails sent from your domain. 

As an example, p=reject; pct=50 means that 50% of emails are subject to the strictest policy, while the remaining 50% are subject to the next strictest policy.

 

Drip recommends starting off more lenient and increasing the strictness over time as DMARC establishes itself upon your sending domain reputation and sending behavior.