Demystifying DMARC: A guide to preventing email spoofing

DMARC can stop spoofed spam and phishing from reaching you and your customers, protecting your information security and your brand. However, complexity and misconceptions deter many organizations from ever deploying it. Part mythbusting , part implementation guide, this post explains the shortcomings of SPF and DKIM, what DMARC is, how to deploy DMARC properly, and how to respond to DMARC reports – all without the need for an additional vendor, thanks to open source software!

Direct link to presentation

Modern email authentication relies on a combination of three standards: SPF, DKIM, and DMARC. These standards help ensure that a message came from a server related to the domain owner and was not spoofed.

Sender Policy Framework (SPF)

SPF was the first widely adopted standard for combating email spoofing. Despite its limitations in preventing spoofing, most email recipients expect you to have it deployed on your domain. For example, Gmail/G-Site/Google will throttle incoming emails from domains that do not have a valid SPF record.

How SPF works

SPF is defined in RFC 7208. It works by checking for a specially formatted DNS TXT record in the domain of the mail from header in the SMTP transaction. This SPF record describes which servers are authorized to send as that domain by using mechanisms to identify authorized IP addresses and hostnames, or even include the SPF records of other domains.

Every SPF record is a TXT record at the root of a domain or subdomain that starts with v=spf1. From there, mechanisms are used to describe mail servers are allowed (or not allowed) to send email as that domain or subdomain. A domain or subdomain can only have one SPF record, but each subdomain can have its own SPF record.

Some mechanisms like a, mx, include, and redirect use additional DNS lookups to work. SPF has a maximum DNS lookup limit of 10, including any included records. Any SPF record that would require more than 10 DNS lookups to resolve is invalid! This is a common mistake to make when deploying SPF.

To work around this limit, send email from different subdomains. Each subdomain needs its own SPF record and has its own set of limits for that record. For example, you could send newsletters from news.example.com, and invoices from billing.example.com.

You might not even need to include every vendor in your SPF records anyway. If the vendor supports DKIM signing, you can rely on that to pass DMARC, even if the sender is not in your SPF record. Just make sure you are using ~all in your SPF record.

v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all

Mechanisms listed in the SPF record have an implicit pass (i.e. +) qualifier in front of them. Possible qualifiers are:

Most SPF records (except for those that are designed to be included in other SPF records) end with an all modifier. The all modifier consists of the word all with a qualifier in front of it. The all modifier states how emails should be treated that do not match any of the listed mechanisms.

SPF’s weakness: Relying on SMTP headers

It is a common misconception that SPF stops email spoofing. At best, it makes things a tiny bit more difficult on an attacker.

Remember, SPF checks for an SPF record at the domain in the mail from header in the SMTP transaction (also known as the envelope from), not the message from header that the receiving mail client sees, The SMTP transaction are not visible to the end client, even when viewing the message headers.

This means that an attacker can use SMTP headers to direct the target’s mail server to check a domain that the attacker controls, which contains an authorizing mechanism for the mail server the attacker is using, while spoofing a completely different domain for the target to see in the message from header!

In the example telnet screenshot below, the attacker is able to get the receiving email server to check the SPF record of a domain that the attacker controls (i.e. infosecspeakeasy.org), while spoofing the target’s own domain (i.e. cincykitchenandbath.com) in the message from header, which is the from address that the target user will see.

This sort of domain mismatch occurs legitimately when a mailbox rule forwards a message from another domain. The message from domain will stay the same, but the SMTP mail from header will contain the domain of the forwarding mail server.

DKIM signatures, on the other hand, are part of the message headers, and survive message forwarding. Therefore DKIM alignment is much more critical than SPF alignment.

Example SPF records

Once you know exactly which email services legitimately send as the domain (DMARC reports will tell you), update the SPF record accordingly, and change the ?all modifier to ~all.

SPF record for domains that send emails from their incoming gateways and are missing SPF records

v=spf1 mx ?all

This record explicitly authorized any servers listed in the domain’s MX record, while treating all others as neutral. This is a good temporary SPF record for new domains or newly acquired domains that do not already have a SPF record.

Here are some good examples of SPF records for common cloud email providers:

Office 365

v=spf1 include:spf.protection.outlook.com ?all

G-Suite

v=spf1 include:_spf.google.com ?all

Proofpoint Essentials

v=spf1 a:dispatch-us.ppe-hosted.com a:dispatch-eu.ppe-hosted.com ?all

SPF record for domains that do not send email (e.g. parked domains)

v=spf1 -all

This record explicitly states that no mail servers are authorized to send email as this domain.

This must be added to all domains that do not send email, inducing parked domains.

DomainKeys Identified Mail (DKIM)

DomainKeys Identified Mail (DKIM) is a email message authentication standard, defined in RFC 6376. Because DKIM authenticates the message headers , rather than the SMTP headers, DKIM authentication survives intact when a message is directly forwarded (e.g. via a mailbox rule).

DKIM message headers

Here’s an example DKIM header

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; c=relaxed/simple; l=1234; t=1117574938; x=1118006938; h=from:to:subject:date; bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR

Required tags

Optional tags

The receiving mail server uses the selector (s=) and domain (d=) tags to look up the public key as a DNS TXT record at

<selector/s=>._domainkey.<domain/d=>

In the above signature example, the receiving server would look for the DKIM key at:

TXT s1._domainkey.example.com

DKIM public key records

DKIM public key records are formatted as:

v=DKIM1; k=rsa; p=<public key>;

Lines in DNS TXT records are truncated at 256 characters. If the record is longer, it must be split into separate lines in the same record in order to be valid.

DKIM public key records can be validated for syntax using the DKIM record lookup tool at MX Toolbox.

Recommended tags

Required tags

Optional tags

Notes in DKIM key records

The DKIM selector (subdomain) is chosen by the vendor and is often non-descriptive. You can use an arbitrary string in the n (i.e., notes) tag in the DKIM record to make a note of the vendor’s name, so you know which DKIM key is used by which vendor as you audit your DNS records.

For example, if “matketingco” asked you to publish the following DKIM TXT record:

randomselector._domainkey.example.com TXT "p=base64Key"

You should create the record this way instead:

randomselector._domainkey.example.com TXT "v=DKIM1; n=marketingco; k=rsa; p=base64Key"

DKIM key rotation

It is generally recommended to rotate DKIM keys once per month, or at least after you suspect that the DKIM private key has been compromised. Most email/marketing services will handle key rotation for you when you configure your domains for DKIM, but some almost never rotate their keys.

Unlike web and email certificates, the domain/email address is not part of the PKI. DKIM does not use certificates.. The domain is listed in the d= header tag.Therefore, you do not need a separate public/private key pair for each domain.

You should create two key pairs, and store the public keys under two different selectors, for example:

s1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=<public key>;"

s2._domainkey.example.com TXT "v=DKIM1; k=rsa; p=<a different public key>;"

With CNAME records, your other domains can use the same selectors and keys:

s1._domainkey.example.net CNAME s1._domainkey.example.com.

s2._domainkey.example.net CNAME s2._domainkey.example.com.

Third party services will often have you authorize their DKIM keys on your domains using CNAME records and will then validate that those records exist before signing email, so they can handle key changes for you.

If you are using your own keys, it is up to you to manage them, preferably using automation. Start by signing all of your emails using the first selector. When it is time to rotate the keys, sign all outgoing email using the s2 sector. After a week of not using the key at the s1 selector, replace the key at the s1 selector.

When it is time to rotate keys again, start using the s1 selector exclusively, wait a week, then replace they key at the s2 selector with a new key, so it will be ready for the next rotation.

Unless a key is known to have been compromised, it is important to wait a week (i.e., 7 days) before replacing it, as some receiving mail servers will cache the public key at a given selector for up to a week.

Using this ping-pong key rotation scheme, you ensure that email is always signed with a valid, secure key.

1. Start exclusively signing with the other selector.
2. Wait 7 days.
3. Replace the key at the old selector so it is ready for the next rotation.
4. Go to step 1.

DKIM’s weakness: arbitrary d= values

Without DMARC, the d= value in a DKIM signature header is not required to match the same domain that the user sees in the message From header. An attacker can place a valid DKIM signature header in an email with a d= value that points to a domain the attacker controls, allowing DKIM to pass while still spoofing the from address to the user.

Domain-based Message Authentication, Reporting, and Conformance (DMARC)

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is defined in RFC 7489. DMARC ensures that the SPF and DKIM authentication mechanisms actually authenticate against the same base domain that the end user sees.

In order to be useful, a DMARC DNS record must be published by a domain owner, and email recipients must honor this record, including its enforcement policy, and at least send back aggregate reports if requested by the domain owner.

A message passes a DMARC check by passing DKIM or SPF, as long as the related indicators are also in alignment with the message’s from address.

DKIM alignment is more important than SPF, because only DKIM remains aligned when a message is forwarded via a mailbox rule.

DMARC reports

DMARC has two report types: aggregate and forensic. email recipients that honor DMARC send these reports back to domain owners in emails sent to addresses listed in the domain’s DMARC record. There reports contain very useful information for debugging message alignment and identifying malicious spoofing campaigns.

DMARC policies

DMARC requires domain owners to set a policy (p=) tag in their DMARC record. This policy tells recipients how they should react to an email that appears to come from that domain based on the message from header but does not pass DMARC alignment.

Even if a domain has a DMARC policy set to p=none, mail services may still display warnings to their users in the event of a DMARC failure, as shown in this screenshot of a valid email from a retail credit service, displayed in ProtonMail and Gmail.

Authentication-Results headers

As an email gateway evaluates SPF, DKIM, and DMARC, it adds the Message-Authentication headers to the email. Users and administrators can use these headers to determine which checks passed or failed, and why.

In the example above, the mail server mail17i.protonmail.ch added the following headers to the email:

Authentication-Results: mail17i.protonmail.ch; dmarc=fail (p=none dis=none) header.from=[redacted].com
Authentication-Results: mail17i.protonmail.ch; spf=pass smtp.mailfrom=noreply_[redacted]_portal=[redacted].com__0-28eb251z589s1s@zihu5s1p6odwjt9p.s3cycftqbacrhjk9.hf76qay.3-1ffzneao.na45.bnc.salesforce.com
Authentication-Results: mail17i.protonmail.ch; dkim=none

Email headers are added and read from the bottom to the top.

First, the server notes that the message has not been DKIM signed.

Then, SPF is checked, with a SMTP mail from header value of noreply_[redacted]_portal=[redacted].com__0-28eb251z589s1s@zihu5s1p6odwjt9p.s3cycftqbacrhjk9.hf76qay.3-1ffzneao.na45.bnc.salesforce.com, and SPF passed. A salesforce.com address was used so that Salesforce can keep track of bouncebacks, and avoid sending to invalid email addresses in the future. SPF passed.

Finally, DMARC is checked, which fails, because the message is not DKIM signed, and the base of the SMTP mail from domain used by SPF (salesforce.com) does not match the base domain in the message from header ([redacted].com). dis=none (short for message disposition) indicates that the message was still delivered, because the mail server noted that [redacted].com has a DMARC policy of p=none.

The retail credit service should resolve the DMARC failures by configuring Salesforce to DKIM sign the messages, and then publish the DKIM public key as a DNS TXT record on [redacted].com.

Note: If you route your incoming email from one gateway service to another, such as from an IronPort to Office 365, by the time an email reaches a user’s mailbox, the information from Office 365 in the Authentication-Results header will always show that SPF and DMARC passed, since the IronPort is authorized to send as your domains when messages are forwarded to Office 365. The results of the original IronPort check that occurs before the message reaches Office 365 are stored in the Authentication-Results-Original header.

Policy records

DMARC policy records are placed at a TXT record at the _dmarc subdomain. Subdomains of the TLD/base domain automatically inherit this DMARC policy record, or they can have their own record at their own _dmarc subdomain.

Here is an example DMARC policy record

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]"

Required tags:

Recommended tags

These tags tell recipients where and how to send reports.

Recipients are only obligated to send reports to the first two rua and ruf addresses. They might not send to any additional address listed.

Not recommended tags

Authorization records

If an email address in rua or ruf has a different base domain than the domain of the policy record, an authorization record must be added to the base domain of the email address to indicate that it accepts reports about that domain. For example, if [email protected] also needed to accept reports for example.net, the poly record for example.net would look like this:

_dmarc.example.net TXT "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]"

Because example.net is a different base domain than example.com, the following record needs to be added to example.com to indicate that it accepts reports about example.com:

example.net._report._dmarc.example.com TXT "v=DMARC1"

Deployment steps

1. Configure email gateways to honor DMARC records and send aggregate DMARC reports.
2. Inventory domains.
3. Deploy SPF.
4. Deploy DKIM.
5. Set up mailbox for receiving DMARC reports.
6. Deploy DMARC DNS records.
7. Monitor incoming DMARC reports.
8. Adjust SPF, DKIM signing, and DMARC policies as needed.

Calendar invites forwarded by Outlook violate DMARC

Calendar events from DMARC protected domains forwarded by outsiders using Outlook will fail DMARC.  Unfortunately, unlike a normal forwarded email, calendar events forwarded using Outlook are “sent on behalf of” the meeting organizer. Instead of using the address of the person who forwarded the email in the from header, Outlook uses the address of the meeting organizer.  The address of the person who did the forwarding is placed in the Sender header, which DMARC does not use.

If the domain of the meeting organizer has an enforced DMARC policy (i.e., p=quarantine, or p=reject), and the recipient mail server honors DMARC, the message will not be delivered, because DMARC does not allow an unauthorized mail server (i.e., the forwarding mail server) to send an email as the organizer’s domain.

This is a known problem with Outlook that Microsoft has so far not addressed. In the meantime, tell anyone who wants to forward calendar events to do so by clicking on the three dots, and clicking Forward as Attachment, instead of clicking on the usual Forward button.

On Outlook for macOS, calendar events must be forwarded by clicking on Message> Forward as Attachment in the Menu Bar.

FAQs

How can I check a DKIM signature?

Send an email to a Gmail account. They have a nice UI that shows the DKIM status of a message.

What if a third-party sender can’t support DMARC?

1. Some vendors don’t know about DMARC yet; ask about SPF and DKIM/email authentication.
   Check if they can send through your email relays instead of theirs.
2. Do they really need to spoof your domain? Why not use the display name instead?
3. Worst case, have that vendor send email as a specific subdomain of your domain (e.g. [email protected]), and then create separate SPF and DMARC records on news.example.com, and set p=none in that DMARC record.

Do not alter the p or sp values of the DMARC record on the Top-Level Domain (TLD) – that would leave you vulnerable to spoofing of your TLD and/or any subdomain.

Further reading on this problem.

How can I get more forensic reports?

Often, you will find a service that sends email that passes SPF alignment, but not DKIM alignment, but you might not know which email workflow has the problem, because you won’t get many forensic reports, since at SPF is aligned.

Try setting fo=1 in your DMARC policy record.

By default, fo is implicitly set to 0. DMARC failure/forensic reports are only sent if all authentication mechanisms (i.e., SPF and DKIM) fail to produce an aligned “pass” result.

Setting fo=1 in the DMARC policy record will provide forensic/failure reports if any authentication mechanisms fail.

This is noisy, but very useful for troubleshooting DKIM when SPF is passing, Remove the fo tag, or set it to 0 once troubleshooting is complete.

What about mailing lists?

When you deploy DMARC on your domain, you might find that messages relayed by mailing lists are failing DMARC, most likely because the mailing list is spoofing your from address, and modifying the subject, footer, or other part of the message, thereby breaking the DKIM signature.

Mailing list best practices

Ideally, a mailing list should forward messages without altering the headers or body content at all. Joe Nelson does a fantastic job of explaining exactly what mailing lists should and shouldn’t do to be fully DMARC compliant. Rather than repeat his fine work, here’s a summary:

Do

• Retain headers from the original message.
• Add RFC 2369 List-Unsubscribe headers to outgoing messages, instead of adding unsubscribe links to the body.

  List-Unsubscribe: <https://list.example.com/unsubscribe-link>
  

• Add RFC 2919 List-Id headers instead of modifying the subject.

  List-Id: Example Mailing List <list.example.com>
  

Modern mail clients and webmail services generate unsubscribe buttons based on these headers.

Do not

• Remove or modify any existing headers from the original message, including From, Date, Subject, etc.
• Add to or remove content from the message body, including traditional disclaimers and unsubscribe footers.

In addition to complying with DMARC, this configuration ensures that Reply and Reply All actions work like they would with any email message. Reply replies to the message sender and Reply All replies to the sender and the list.

Even without a subject prefix or body footer, mailing list users can still tell that a message came from the mailing list, because the message was sent to the mailing list post address, and not their email address.

Configuration steps for common mailing list platforms are listed below.

Mailman 2

Navigate to General Settings, and configure the settings below

Navigate to Non-digest options, and configure the settings below:

Navigate to Privacy Options> Sending Filters, and configure the settings below:

Mailman 3

Navigate to Settings> List Identity

Make Subject prefix blank.

Navigate to Settings> Alter Messages

Configure the settings below:

Navigate to Settings> DMARC Mitigation

Configure the settings below

Create a blank footer template for your mailing list to remove the message footer. Unfortunately, the Postorius mailing list admin UI will not allow you to create an empty template, so you’ll have to create one using the system’s command line instead, for example:

touch var/templates/lists/list.example.com/en/list:member:regular:footer

Where list.example.com the list ID, and en is the language.

Then restart mailman core.

Workarounds

If a mailing list must go against best practices and modify the message (e.g., to add a required legal footer), the mailing list administrator must configure the list to replace the from address of the message (also known as munging) with the address of the mailing list, so they no longer spoof email addresses with domains protected by DMARC.

Configuration steps for common mailing list platforms are listed below.

Mailman 2

Navigate to Privacy Options> Sending Filters, and configure the settings below

Mailman 3

In the DMARC Mitigations tab of the Settings page, configure the settings below:

LISTSERV

LISTSERV 16.0-2017a and higher will rewrite the from header for domains with a DMARC quarantine or reject policy.

Some additional steps are needed for Linux hosts.

DMARC deployment guides

• NIST Special Publication 800-177 – Trustworthy Email
• DMARC Overview
• Proofpoint Email Authentication Guide
  • Proofpoint does not currently send any DMARC reports
    
• DMARC guide for G Suite
• DMARC guide for Office 365
  • Note: Office 365 does not currently send any DMARC reports, but you can analyze DMARC data from Office 365 using the free Valimail Monitor for Office 365 service
• Complete DKIM and DMARC deployment guide for Cisco AsyncOS
• Generic DMARC Deployment guide – Dmarcian
• List of DMARC Support Status of SaaS Services – Dmarcian
• DMARC Guide for 3rd Party Senders – Dmarcian
• Solutions to common problems – Dmarcian
• Reference library by OnDMARC
• SPF Deployment Guide – MSDN
• RFC 7489

SPF and DMARC record validators

• checkdmarc – A Python module and CLI tool I wrote to validate and parse SPF and DMARC records
• trustymail – By DHS; checks for compliance with BOD 18-01, including SPF, DMARC, and STARTTLS
• DNS Checker – Check DNS propagation worldwide

DMARC report processing services

• Agari – Most popular provider to federal agencies, partners with ISACs and others – “Contact us” pricing
• Dmarcian – Public, straightforward pricing, free public reference guides
• OnDMARC – Low cost services, extensive free public reference guides
• Proofpoint Email Fraud Defense – “Contact us” pricing; most useful for current Proofpoint customers
• Valimail – Offers automated SPF/DKIM/DMARC DNS record generation
• parsedmarc – Open source self-hosted DMARC report processing and analytics

DMARC adoption

• Email Authentication Policy and Deployment Strategy for Financial Services Firms (BITS/The Financial Services Roundtable – Feb. 2013)
• DHS Binding Operational Directive (BOD) 18-01 (Oct. 2017)
• Fifty-Seven Percent of Email “From” Healthcare Industry is Fraudulent (H-ISAC – Nov. 2017)

DMARC compliant services

Blackbaud

Payment and CRM solutions for non-profits

• https://www.blackbaud.com/solutions
• https://docs.blackbaud.com/email-resource-center/faqs/best-practices-faq#what-is-an-spf-record-and-how-do-i-create-it
• https://kb.blackbaud.com/articles/Article/65862

Constant Contact

• https://www.constantcontact.com/email-marketing
• https://www.constantcontact.com/pricing
• https://knowledgebase.constantcontact.com/guides/KnowledgeBase/5932-self-publishing-for-authentication

Cvent

Cvent planner supports alignment via SPF and DKIM.

Add the following to your SPF record:

include:cvent-planner.com

Contact Cvent support to set up DKIM signing as your domain.

• https://www.cvent.com/
• https://knowledge.ondmarc.com/articles/1977363-cvent-planner-spf-and-dkim-set-up

Emma

• https://myemma.com/pricing
• https://support.e2ma.net/Resource_Center/Account_how-to/deliverability-best-practices#5._Authenticate_your_sending_domain

Elastic Email

Reasonably priced, fully DMARC compliant marketing and transactional email.

• https://elasticemail.com/pricing/
• https://elasticemail.com/marketing-features/
• https://elasticemail.com/transactional/
• https://elasticemail.com/resources/settings/spf-dkim-tracking-faq/

GlobalCert SecureMail Gateway

• https://support.globalcerts.net/portal/kb/articles/dkim-signatures

HealthcareSource

Healthcare talent management SaaS. Contact support and let them know that you need SPF and DKIM set up for DMARC alignment.

• https://www.healthcaresource.com/
• [email protected]

HubSpot

Good option if a full Customer Relationship Management (CRM) platform is needed.

• https://www.hubspot.com/pricing/marketing
• https://www.hubspot.com/products/marketing
• https://knowledge.hubspot.com/articles/kcs_article/email/can-i-use-a-dmarc-policy-with-hubspot

JangoMail

Full-featured email marketing

Add include:jangomail.com to your SPF record.

• https://jangomail.com/features/
• https://jangomail.com/pricing/
• https://jangomail.com/send-email-via-api/
• https://jangomail.com/domainkeysdkim/

JangoSMTP

Transactional email service used by IBM Phytel (see separate entry below) and others.

Add include:jangomail.com to your SPF record.

• https://jangosmtp.com/features/
• https://jangosmtp.com/pricing/
• https://jangomail.zendesk.com/hc/en-us/articles/200660154-DomainKeys-DKIM

MailChimp

Extremely cheap bulk marketing email; extremely expensive transactional email.

• https://kb.mailchimp.com/accounts/email-authentication/verify-a-domain#Verify-Domain-in-Account-Settings
• https://kb.mailchimp.com/accounts/email-authentication/set-up-custom-domain-authentication-dkim-and-spf

Mandrill

A MailChimp add-on service for transitional email

• https://kb.mailchimp.com/mandrill/mailchimp-vs-mandrill
• http://mandrill.com/pricing/
• https://mandrill.zendesk.com/hc/en-us/articles/205582267-What-are-SPF-and-DKIM-and-do-I-need-to-set-them-up
• Set SMTP envelope sender for SPF alignment in the Mandrill dashboard
  Settings -> Domains -> Tracking and Return Path Domain

Mailgun

• https://www.mailgun.com/pricing
• https://documentation.mailgun.com/en/latest/user_manual.html#verifying-your-domain

Mailjet

Email and SMS marketing.

• https://www.mailjet.com/pricing/
• https://www.mailjet.com/docs/spf-dkim-guide

Net-Results

Marketing automation

• https://www.net-results.com/pricing/
• http://support.net-results.com/index.php/Domain_Branding

OnSolve Mir3

Mass notification system for employees, contractors, students, etc.

Mir3 supports DKIM alignment via DKIM.

Contact your Mir3 account manager to have them set up DKIM signing/email whitelabeling.

• https://www.onsolve.com/solutions/products/mir3/
• https://www.onsolve.com/resources/support/

Phytel (sent via JangoSMTP)

IBM Phytel is used by healthcare providers to send appointment reminders and other information to their patients. Emails are relayed through JangoSMTP.

Add include:jangomail.com to your SPF record.

Contact IBM Phytel support and ask them to configure DKIM signing.

• [email protected]
• https://www-01.ibm.com/support/docview.wss?uid=ibm10716407
• https://www.ibm.com/watson-health/phytel

Safe Pay Services

A payment processor that supports DMARC alignment via SPF and DKIM.

Add a:mail.safepayservices.com to your SPF record.

Contact support for details.

• https://safepayservices.com/services
• https://safepayservices.com/contact

Salesforce Marketing Cloud

• https://www.salesforce.com/editions-pricing/marketing-cloud/
• https://www.salesforce.com/products/marketing-cloud/email-marketing/
• https://help.salesforce.com/articleView?id=emailadmin_create_secure_dkim.htm&type=5

SendGrid

• https://sendgrid.com/solutions/email-marketing/
• https://sendgrid.com/pricing/
• https://sendgrid.com/docs/ui/account-and-settings/how-to-set-up-domain-authentication/

Sendinblue

Not as cheap as Elastic Email, but cheaper than SendGrid and Mandrill, with options for SMS.

• https://www.sendinblue.com/pricing/
• https://www.sendinblue.com/features/
• https://help.sendinblue.com/hc/en-us/articles/209577385-Understand-SPF-DKIM-and-DMARC-protocols

Simplee

B2C medical billing

According to Simplee support as of 2019-05-23, in order to support DKIM signing, they need to purchase a domain authentication package from Salesforce, with the cost passed on to the customer, and have the Simplee customer delegate a domain or subdomain to Salesforce via NS records:

• ns1.exacttarget.com
• ns2.exacttarget.com
• ns3.exacttarget.com
• ns4.exacttarget.com

Costs include:

• One-time setup fee: $350 for Simplee to cover implementation and setup costs
• Annual Fee: $1,500 per year per domain (pass-through expense via Salesforce) + $39 Salesforce Purchase Order Fee

For for information, contact Simplee support at https://support.simplee.com/hc/en-us/requests/new

Symantec MessageLabs

• https://support.symantec.com/en_US/article.HOWTO126432.html

Services that must use your SMTP relays to be fully DMARC compliant

• Qualtrics
• ServiceNow

Incompatible services

Some services do not do any DKIM signing, or use their own domain came in the DKIM d= tag, making the signature unaligned with the message from address domain they are spoofing.

There are different two ways to work around this problem, each with its own benefits and drawbacks:

1. Have the vendor send emails from their domain instead of yours
2. Configure the service to use a specific subdomain of your domain in the message from address. Then, create a separate DMARC record with p=none under that specific subdomain.

By having a service send as its own domain, you loose branding in the from email address, but it will not cause additional complexity or risk.

Publishing a DMARC p=none policy on a specific subdomain allows spoofing of that specific subdomain, without weakening DMARC enforcement for other subdomains, or the top level domain. This allows you to keep your domain in the from address, but also opens up that specific subdomain to spoofing from anyone.

UL PureSafety

DKIM signing as customer domains is not currently supported by UL PureSafety OHM.
Most outbound email notifications in OHM are configured by the customer, including the From address they will be sent with. The user(s) should go through the screens where they have set them to various customer addresses and change them to a generic puresafety.com address, such as “[email protected].” They should also update the Body of each email template to include appropriate contact information.

Volgistics

Volgistics does not currently support DKIM signing, so the account administrator will need to complete the following steps to configure Volgistics to send email as Volgistics.com:

1. Choose Setup from the menu in the account
2. Expand Messages
3. Click the “Ground Rules” link
4. In the “From address” section, select the “Use [email protected] as the from address (recommended)” option
5. Click the Save button

Bonus steps

These steps aren’t required to deploy DMARC, but they can help to make your email more secure.

Verify TLS

TLS ensures that messages are encrypted on their way to your mail servers. STARTTLS allows email clients to upgrade from a plan text connection to an encrypted one.

To check STARTTLS, run:

To check the standard secure SMTP port, run:

Brand Indicators for Message Identification (BIMI)

Brand Indicators for Message Identification (BIMI) is an emerging standard that some mail applications/services are starting to follow (currently only Yahoo, with more services throughout 2019) . When a mail client uses BIMI, it first checks to see if the message passed DMARC alignment. If the DMARC policy is set to enforcement (i.e. p=quarentine or p=reject) and DMARC alignment has passed, the mail/webmail client then checks for a BIMI assertion record at the message from domain. This record points the client to a SVG file publicly hosted on a web server, which is then displayed in the client UI, next to the message from information.

To set up BIMI, host a SVG graphic file at a publicly accessible HTTPS URL, then add a BIMI assertion TXT DNS record like this one.

default._bimi.example.com TXT "v=BIMI1; l=https://cdn.example.com/logo.svg"