1. Internal RG Wiki
  2. Internal Documents
  3. Help Resources for the Support Team

Guide for Implementing SPF, DKIM, and DMARC to Address Email Bounce Issues

We've observed an increase in email bounce issues recently, partly due to Google and Yahoo tightening their requirements. Sender requirements will officially take effect starting in February. Here's a quick guide to assist you in setting up the necessary SPF, DKIM, and DMARC records for our clients:

Disclaimer: We recommend having the client obtain these records directly from their email hosting provider whenever possible.

SPF (Sender Policy Framework): 

SPF is an email authentication protocol preventing email spoofing by specifying authorized mail servers for a domain.

  • In MCP, DNS settings for Google will automatically generate the required SPF record.
  • For Microsoft, it'll depend on various factors; it may be safer to have the client provide the SPF record they've obtained from their provider.
  • Instruct clients using other email services (Rackspace, Bluehost, etc...) to directly obtain their SPF records from the provider and send them to us for installation.
  • In most cases, it'll be a single email server but we've seen cases where an additional email server needed to be added.
  • Example SPF TXT record with two email servers (Google and Microsoft):
    • Name: @
    • Value "v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all"
  • Example SPF TXT record with one email server (Google):
    • Name: @
    • "v=spf1 include:_spf.google.com ~all"

DKIM (DomainKeys Identified Mail):

DKIM digitally signs email messages, ensuring content integrity and confirming sender authenticity.

  • Advise clients to generate DKIM keys using their email provider's settings. They may need to reach out to their email provider's support team for assistance.
  • Request them to forward the DKIM public key to you.
  • Install the DKIM public key in the AWS
  • Example DKIM TXT record:
    • Name: _domainkey
    • Value:  "v=DKIM1; k=rsa; p={public key}"

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

DMARC builds on SPF and DKIM, providing policies for handling authentication results and generating reports to prevent email fraud and phishing.

  • Clients can request a DMARC record from their provider. Alternatively, you can create one for them.
  • If you're creating the DMARC record for the client, add a new TXT record for the subdomain _dmarc.
  • Define the DMARC policy within the TXT record. For example:
    • Name: _dmarc
    • Value: "v=DMARC1; p=none; rua=mailto:your@email.com; ruf=mailto:your@email.com"
  • v=DMARC1: DMARC version.
  • p=none: Monitoring mode (no specific action for failing emails).
  • rua=mailto:client@email.com: Reporting address for aggregate reports. This can be any email address the client would like to receive the aggregate reports. (Optional)
  • ruf=mailto:client@email.com: Reporting address for forensic reports. This can be any email address the client would like to receive the forensic reports. (Optional)
  • Please note: Using the same email address for both `rua` and `ruf` is valid, and not having either is acceptable in some cases.

Implementing SPF, DKIM, and DMARC collectively enhances email authentication, reducing bounce issues and improving the reliability of email communications.