Email Fraud Protection

Build Your DMARC Record in 15 Minutes

Posted by Amy Gorrell on

Implementing DMARC (Domain-based Message Authentication Reporting and Conformance) is the best way to defend your customers, your brand, and your employees from phishing and spoofing attacks.

DMARC is built upon two other authentication protocols: SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). You should have SPF and DKIM on your Envelope From and Friendly From domains before proceeding with DMARC. (For a refresher on how DMARC works, check out this blog post.)

While the implementation process can get tricky, building your DMARC record doesn’t have to be. Follow the steps below to build your DMARC record in 15 minutes—or less!

Step 1: Verify domain alignment (aka identifier alignment)
Begin by opening the email headers from the emails you send. Identify the domain or subdomain listed in the following places:

  • The Envelope From (e.g.., Return Path or Mail-From)
  • The “Friendly” From (i.e., “Header” From)
  • The d=domain in the DKIM-Signature

Are your domain names identical? If so, then your domains are aligned and you will be able to instruct mailbox providers to reject any malicious emails purporting to be from your brand. If not, you can still proceed to create your DMARC record and work with your messaging, IT, and/or security teams to get aligned.

Step 2: Identify email accounts to receive DMARC reports
Through DMARC, you will receive aggregate and forensic (message level) reports daily. Designate the email account(s) where you want to receive these reports. You may want to use two separate accounts, as you could get inundated with the data.

DMARC reports are very difficult to parse because they are provided in raw format. Partnering with a company like Return Path can help you and your team make sense of them—fast.

Step 3: Learn the DMARC tags|
DMARC tags are the language of the DMARC standard. They tell the email receiver (1) to check for DMARC and (2) what to do with messages that fail DMARC authentication.

There are many DMARC tags available, but you do not have to use them all. In fact, we recommend keeping it simple. Focus on the v=, p=, fo=, rua, and ruf tags. Our recent blog post, Demystifying the DMARC Record breaks down what tags to use and why.

Step 4: Generate your DMARC record with Return Path’s DMARC Creation Wizard
Using our DMARC Creation Wizard, generate a DMARC text record in your DNS for each sending domain. Set the mail receiver policy to “none,” indicating DMARC’s “monitor” mode.

Screen Shot 2016-02-01 at 10.08.18 AM

With DMARC in monitor mode, you can gather the information on your entire email ecosystem, including who is sending email on behalf of your brand, what emails are getting delivered, and what emails are not.

Request to receive the daily aggregate and forensic reports by specifying your email address in the rua tag and the ruf tag, respectively. Use the email address(es) you identified in step three above.

Your record should look something like this:

v=DMARC1; p=none; fo=1; rua=mailto:dmarc_agg@auth.example.com;ruf=mailto:dmarc_afrf@auth.example.com

Congratulations! You have created your DMARC record. The next step is implementation.

Step 5. Implement your DMARC record into DNS
Work with your DNS server administrator to add your DMARC record to DNS and start monitoring your chosen domain.

That might be your primary domain or a carefully selected test domain. You will start receiving reports and see where email traffic using that domain is coming from. Perhaps you will identify some vendors or partners you didn’t realize were sending on your behalf. Perhaps you will be surprised to find that there is—or isn’t—a significant volume of fraudulent messages using that domain and where those messages are coming from.

To learn about how other companies, industries, and mailbox providers are using DMARC to eliminate the impact of email fraud, download The DMARC Intelligence Report.

About Amy Gorrell

Amy Gorrell is a Strategic Project Manager for Return Path's Email Fraud Protection team. Amy works with some of our top-tier clients to help eliminate the impact of email fraud. When she's not fighting cyber crime you can find her enjoying the many outdoor activities Colorado has to offer. You can connect with Amy on LinkedIn @Amy Gorrell or follow her on Twitter @amy_gorrell.

Read more from this author

  • Kathie Montgomery

    Can the friendly from be something simple, like Happy Coffee and the from email address be happycoffee@happycoffee.com? Or do both the friendly from name and the email address need to match, so both would be happycoffee@happycoffee.com? I think if it would be the latter, that brands will have a hard time with that. It’s not a very nice looking friendly from name. Thanks for your help to clarify.

    • Amy Gorrell

      Hi Kathie, for DMARC to pass, the friendly from domain and the mail from domain need to match. The portion before the @ symbol does not need to be anything specific. So in your example, the friendly from could be anyname@happycoffee.com and the mail from domain would need to @happycoffe.com as well. The display name is separate, however, it would also be recommended to use a recognizable display name as well.

      • Kathie Montgomery

        Thanks, Amy! So maybe I’m confusing terms. It sounds like the display name then doesn’t have to also be the email address for DMARC to pass. So in my example, the display name could simply be “Happy Coffee”, correct? I read something elsewhere that when the display name and the from email address are identical, it creates “domain alignment” and is an added level of threat protection. But as a brand marketer, having an email address as the display name looks bad. Are you familiar with this domain alignment concept and do you have a suggestion for brands, especially financial ones that are often at higher risk of phishing in the first place? Thanks again.

        • Amy Gorrell

          Hi Kathie, yes, your display name could be “Happy Coffee.” From a DMARC perspective domain alignment refers only to the friendly from domain (header from) matching the mail-from domain and the DKIM domain; display name does not have to be a domain.

  • Chad Criswell

    I have set up DMARC on several of my domains using your tool (thank you) to generate the TXT record. I do have one question though as it is not covered in the article. Once I am confident that legitimate messages are not getting marked should I change the record to REJECT instead of being on NONE? I assume that that would make the systems reject any non-legitimate emails?

    • Amy Gorrell

      Yes, once you feel comfortable that all legitimate messages are correctly aligned and signing, it would be a good idea to confirm with the necessary internal parties and move the domain to reject to stop phishing messages from getting into the inbox. You can also check out this additional blog post https://blog.returnpath.com/5-essential-tips-for-implementing-dmarc/ to make sure you are covering all your bases before moving to reject.

  • Hello Amy, this is an excellent post. I’m going to be implementing DMARC on our website, benefacto.org in the next week or so.

    I’ve recently set up SPF and DKIM records both for our main email system (Google Apps) and also for the marketing tool we use (Klaviyo).

    However, on the Klaviyo emails (screenshot attached) the ‘mailed-by’ address (delivery.klaviyomail.com) is not the same as the ‘friendly from’ email (@benefacto.org).

    Would this mean that the Klaviyo emails would all fail DMARC? We’ve set DKIM and SPF up in cPanel for Klaviyo. Cheers, Linz

    • Amy Gorrell

      Hi Linz, if your MailFrom domain (in this case klaviyomail.com) does not match your friendly from domain (in this case benefacto.org) then the SPF alignment check will fail. You could still pass DMARC if your DKIM signature passes and aligns. In order to pass at DKIM in this situation, your d=value (domain value) needs to match your friendly from so it would need to be d=benefacto.org. If neither of those match then the message would fail DMARC.

      • Thanks for the speedy reply Amy.

        I asked our mailer provider to change this and it looks like they have, please see attached.

        If the ‘MailFrom’ domain is a sub domain (send.benefacto.org) of our ‘From’ domain (benefacto.org) will it pass DMARC on the SPF Record, or will it still cause an issue? It looks like we’ll pass on the DKIM element now because they’ve changed the ‘Signed-by’ to benefacto.org but I like belt and braces!

        Cheers,

        Linz

        • Amy Gorrell

          Hi Linz, yes this change will result in an SPF alignment pass. As long as the top level domain (in this case both benefacto.org) are the same then the alignment piece will pass. The only other thing you’ll want to do is make sure that send.benefacto.org has the same SPF as benefacto.org so that the IP look up passes as well.

          • Thanks again Amy.

            I believe our SPF records for send.benefacto.org and benefacto.org are set up to work together correctly, although they’re not exactly the same.

            We’ve got:

            send.benefacto.org is v=spf1 include:sendgrid.net ~all

            benefacto.org is v=spf1 include:send.benefacto.org include:_spf.google.com ~all

            Does that look right to you?

          • Amy Gorrell

            Hi Linz, If I were you I would update the send.benefacto.org SPF record to include the same IPs as the benefacto.org SPF so that the check will pass. Thanks!