Sign In
Deliverability

Understanding Dpia slm rijk Requirements

By Article Monster
October 5, 2025
25 min read

Understanding SPF: Authorizing Email Senders

Dpia slm rijk - Illustration depicting an SPF record authorizing various email senders for a domain, with arrows indicating the flow of email verification.

Sender Policy Framework (SPF) is an email authentication method designed to prevent sender address forgery. It allows domain owners to specify which mail servers are authorized to send email on behalf of their domain. Receiving mail servers can then check the SPF record of the sending domain to verify if the email originated from an authorized source. If the email fails the SPF check, it’s an indication that the email might be spoofed or forged.

Essentially, SPF acts as a “whitelist” for your domain, telling receiving servers, “These are the only servers allowed to send email using my domain.” This helps prevent spammers from forging your email address and sending malicious emails that appear to come from you.

Creating an SPF Record

An SPF record is a TXT record added to your domain’s DNS settings. It consists of a version number (“v=spf1”) followed by a series of mechanisms and qualifiers that define the authorized sending sources. Let’s look at some common mechanisms:

  • ip4: Allows specifying individual IPv4 addresses or ranges.
  • ip6: Allows specifying individual IPv6 addresses or ranges.
  • a: Allows specifying the A record of a hostname.
  • mx: Allows specifying the MX records of a domain.
  • include: Allows including another domain’s SPF record.
  • all: Specifies the policy for emails that don’t match any of the previous mechanisms.

Qualifiers modify the behavior of these mechanisms:

  • +: (Pass) The mechanism is allowed. This is the default if no qualifier is specified.
  • -: (Fail) The mechanism is not allowed.
  • ~: (SoftFail) The mechanism is not preferred, but accepted.
  • ?: (Neutral) The domain makes no assertion about whether the IP address is authorized.

Here are some practical examples:

Example 1: Basic SPF Record

This SPF record allows email from the server with the IP address 192.0.2.10 and any server listed in the MX records for your domain:

v=spf1 ip4:192.0.2.10 mx -all

Explanation:

  • v=spf1: Specifies the SPF version.
  • ip4:192.0.2.10: Allows email from the IPv4 address 192.0.2.10.
  • mx: Allows email from servers listed in the MX records for the domain.
  • -all: Any other source is explicitly disallowed (hard fail).

Example 2: Including a Third-Party Sender

If you use a third-party email service like SendGrid, Mailchimp, or Google Workspace, you’ll need to include their SPF records. For example, to include SendGrid:

v=spf1 include:sendgrid.net -all

Explanation:

  • include:sendgrid.net: Includes the SPF record of SendGrid, allowing them to send emails on your behalf. You would replace `sendgrid.net` with the appropriate domain for your third-party sender.
  • -all: Any other source is explicitly disallowed (hard fail).

Example 3: Multiple IP Addresses and Includes

This SPF record allows email from two specific IP addresses, servers listed in the MX records, and includes the SPF record for Google Workspace:

v=spf1 ip4:192.0.2.10 ip4:198.51.100.20 mx include:_spf.google.com -all

Explanation:

  • ip4:192.0.2.10: Allows email from the IPv4 address 192.0.2.10.
  • ip4:198.51.100.20: Allows email from the IPv4 address 198.51.100.20.
  • mx: Allows email from servers listed in the MX records for the domain.
  • include:_spf.google.com: Includes the SPF record for Google Workspace.
  • -all: Any other source is explicitly disallowed (hard fail).

Important Considerations

When configuring your SPF record, keep the following points in mind:

  • Limit DNS Lookups: SPF records have a limit of 10 DNS lookups. Using too many include mechanisms can exceed this limit, causing the SPF record to fail. Consider using IP addresses directly if possible.
  • Use Hard Fail (-all): A hard fail indicates a clear “no” and is generally preferred for stricter security.
  • Regularly Review and Update: As your email infrastructure changes (e.g., you switch email providers), update your SPF record accordingly.

Expert Tip: Use a tool like `dig` or `nslookup` to verify that your SPF record is correctly published in your DNS. You can also use online SPF record checkers to validate its syntax and identify potential issues.

dig yourdomain.com TXT

This command will query the DNS records for your domain and display the TXT records, including your SPF record (if present).

Implementing DKIM: Email Authentication with Digital Signatures

Dpia slm rijk - Diagram illustrating the DKIM signing process, highlighting the use of private and public keys for authentication.

DomainKeys Identified Mail (DKIM) is another crucial email authentication method that uses cryptographic signatures to verify the integrity and authenticity of emails. Unlike SPF, which focuses on authorizing sending servers, DKIM focuses on verifying that the email content has not been altered in transit and that it truly originated from the claimed sender.

DKIM works by adding a digital signature to the email header using the sender’s private key. Receiving mail servers can then retrieve the corresponding public key from the sender’s DNS record and use it to verify the signature. If the signature is valid, it confirms that the email’s content hasn’t been tampered with and that the sender is authorized to send email on behalf of the domain.

Generating DKIM Keys

The first step in implementing DKIM is to generate a key pair: a private key used for signing emails and a public key that will be published in your DNS record. You can generate DKIM keys using various tools, including OpenSSL or your email provider’s control panel.

Here’s an example of generating a DKIM key pair using OpenSSL:

openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.key

Explanation:

  • openssl genrsa -out private.key 2048: Generates a 2048-bit RSA private key and saves it to the file `private.key`. The 2048-bit key length is recommended for security.
  • openssl rsa -in private.key -pubout -out public.key: Extracts the public key from the private key and saves it to the file `public.key`.

Keep the private key secure. This key should only be accessible to your email server. You will use it to sign outgoing emails.

Creating the DKIM DNS Record

The public key needs to be published as a TXT record in your DNS. The format of the DKIM DNS record is as follows:

selector._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY;"

Explanation:

  • selector: A selector is a string used to identify the specific DKIM key. You can choose any selector, but it’s common to use “default” or a descriptive name. This allows you to rotate keys in the future without disrupting email flow.
  • _domainkey: This is a required prefix for DKIM records.
  • yourdomain.com: Replace this with your actual domain name.
  • v=DKIM1: Specifies the DKIM version.
  • k=rsa: Specifies the key type (RSA in this case).
  • p=PUBLIC_KEY: This is where you paste the actual public key generated earlier. Remove any line breaks from the public key before pasting it into the DNS record.

Example:

Let’s say your selector is “mail” and your public key is:

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwvk2p4dI635j10q6sRj
q2R29T8t1Y+Qx0j7v4Lq8Z0X9r8jWz6c3n2W0a5b7c8d9e0f1a2b3c4d5e6f7g
8h9i0j1k2l3m4n5o6p7q8r9s0t1u2v3w4x5y6z7a8b9c0d1e2f3g4h5i6j7k8l
9m0n1o2p3q4r5s6t7u8v9w0x1y2z3a4b5c6d7e8f9g0h1i2j3k4l5m6n7o8p9q
0r1s2t3u4v5w6x7y8z9a0b1c2d3e4f5g6h7i8j9k0l1m2n3o4p5q6r7s8t9u0v
1w2x3y4z5a6b7c8d9e0f1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0t1u
2v3w4x5y6z7a8b9c0d1e2f3g4h5i6j7k8l9m0n1o2p3q4r5s6t7u8v9w0x1y2z
3a4b5c6d7e8f9g0h1i2j3k4l5m6n7o8p9q0r1s2t3u4v5w6x7y8z9a0b1c2d3e
4f5g6h7i8j9k0l1m2n3o4p5q6r7s8t9u0v1w2x3y4z5a6b7c8d9e0f1a2b3c4d
5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0t1u2v3w4x5y6z7a8b9c0d1e2f3g4h5i6
-----END PUBLIC KEY-----

Your DKIM DNS record would look like this (replace `yourdomain.com` with your actual domain):

mail._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwvk2p4dI635j10q6sRj
q2R29T8t1Y+Qx0j7v4Lq8Z0X9r8jWz6c3n2W0a5b7c8d9e0f1a2b3c4d5e6f7g
8h9i0j1k2l3m4n5o6p7q8r9s0t1u2v3w4x5y6z7a8b9c0d1e2f3g4h5i6j7k8l
9m0n1o2p3q4r5s6t7u8v9w0x1y2z3a4b5c6d7e8f9g0h1i2j3k4l5m6n7o8p9q
0r1s2t3u4v5w6x7y8z9a0b1c2d3e4f5g6h7i8j9k0l1m2n3o4p5q6r7s8t9u0v
1w2x3y4z5a6b7c8d9e0f1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0t1u
2v3w4x5y6z7a8b9c0d1e2f3g4h5i6j7k8l9m0n1o2p3q4r5s6t7u8v9w0x1y2z
3a4b5c6d7e8f9g0h1i2j3k4l5m6n7o8p9q0r1s2t3u4v5w6x7y8z9a0b1c2d3e
4f5g6h7i8j9k0l1m2n3o4p5q6r7s8t9u0v1w2x3y4z5a6b7c8d9e0f1a2b3c4d
5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0t1u2v3w4x5y6z7a8b9c0d1e2f3g4h5i6;"

Important: Ensure there are no extra spaces or line breaks within the public key in the DNS record. This can cause the DKIM verification to fail.

Configuring Your Email Server for DKIM Signing

Next, you need to configure your email server to use the private key to sign outgoing emails. The configuration process varies depending on the email server you’re using. Here’s an example using Postfix with OpenDKIM:

  • Install OpenDKIM:
sudo apt-get install opendkim opendkim-tools
  • Configure OpenDKIM: Create the file /etc/opendkim.conf with the following content:
Syslog                  yes
SyslogSuccess           yes
LogWhy                  yes

UserID                  opendkim:opendkim
Socket                  inet:8891@localhost

KeyTable                refile:/etc/opendkim/KeyTable
SigningTable            refile:/etc/opendkim/SigningTable
TrustedAuthDomains      refile:/etc/opendkim/TrustedAuthDomains

ExternalIgnoreList      refile:/etc/opendkim/TrustedHosts
InternalHosts           refile:/etc/opendkim/TrustedHosts

OversignHeaders         From:Sender:Reply-To:Cc:Subject:Date
  • Create the KeyTable: Create the file /etc/opendkim/KeyTable with the following content:
mail._domainkey.yourdomain.com yourdomain.com:mail:/etc/opendkim/keys/yourdomain.com/mail.private

Replace `yourdomain.com` with your actual domain and `mail` with your selector.

  • Create the SigningTable: Create the file /etc/opendkim/SigningTable with the following content:
*@yourdomain.com mail._domainkey.yourdomain.com

Replace `yourdomain.com` with your actual domain and `mail` with your selector.

  • Create the TrustedHosts file: Create the file /etc/opendkim/TrustedHosts and add your domain and localhost:
127.0.0.1
localhost
yourdomain.com

Replace `yourdomain.com` with your actual domain.

  • Create the key directory and copy the private key:
sudo mkdir -p /etc/opendkim/keys/yourdomain.com
sudo cp private.key /etc/opendkim/keys/yourdomain.com/mail.private
sudo chown opendkim:opendkim /etc/opendkim/keys/yourdomain.com/mail.private
sudo chmod 600 /etc/opendkim/keys/yourdomain.com/mail.private

Replace `yourdomain.com` with your actual domain and `mail` with your selector. Also, replace `private.key` with the actual path to the private key file.

  • Configure Postfix: Add the following lines to /etc/postfix/main.cf:
milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = inet:127.0.0.1:8891
  • Restart OpenDKIM and Postfix:
sudo systemctl restart opendkim
sudo systemctl restart postfix

These steps configure Postfix to use OpenDKIM to sign outgoing emails.

Testing Your DKIM Configuration

After configuring DKIM, it’s essential to test that it’s working correctly. You can send an email to a DKIM analyzer service like `mail-tester.com`. This service will analyze your email and report whether the DKIM signature is valid.

Alternatively, you can examine the email headers of an email you send to a Gmail account. Look for the “Authentication-Results” header, which should indicate whether the DKIM check passed.

Example of a successful DKIM result in Gmail’s “Show Original” view:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@yourdomain.com header.s=mail header.b=...;
       spf=pass (google.com: domain of sender@yourdomain.com designates 192.0.2.10 as permitted sender) client-ip=192.0.2.10; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

This result indicates that DKIM, SPF, and DMARC all passed for the email.

Mastering DMARC: Policy and Reporting for Enhanced Security

Domain-based Message Authentication, Reporting & Conformance (DMARC) builds upon SPF and DKIM to provide a comprehensive email authentication framework. DMARC allows domain owners to specify how receiving mail servers should handle emails that fail SPF and/or DKIM checks. It also provides a reporting mechanism that allows domain owners to receive feedback on email authentication results, helping them identify and address potential issues like spoofing and phishing.

Essentially, DMARC acts as a policy layer on top of SPF and DKIM. It tells receiving servers what to do with emails that don’t pass authentication (e.g., quarantine, reject) and provides a way for domain owners to monitor email authentication activity.

Creating a DMARC Record

A DMARC record is a TXT record added to your domain’s DNS settings. It specifies the DMARC policy and reporting preferences. The DMARC record must be placed at the subdomain `_dmarc` of your domain.

The basic syntax of a DMARC record is:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=POLICY; rua=MAILTO_URI; ruf=MAILTO_URI;"

Explanation:

  • _dmarc.yourdomain.com: Specifies the location of the DMARC record in DNS. Replace `yourdomain.com` with your actual domain.
  • v=DMARC1: Specifies the DMARC version.
  • p=POLICY: Specifies the policy for handling emails that fail SPF and/or DKIM checks. Possible values are:
    • none: Monitoring mode. The receiving server takes no specific action. This is recommended for initial DMARC deployment.
    • quarantine: The receiving server should treat failing emails as suspicious. This typically means placing them in the spam folder.
    • reject: The receiving server should reject failing emails.
  • rua=MAILTO_URI: Specifies the email address to which aggregate reports should be sent. These reports provide a summary of email authentication activity.
  • ruf=MAILTO_URI: Specifies the email address to which forensic reports (failure reports) should be sent. These reports provide detailed information about individual emails that failed authentication. This is less commonly used due to privacy concerns.

Example 1: Monitoring Mode

This DMARC record is in monitoring mode and sends aggregate reports to `dmarc-reports@yourdomain.com`:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com;"

Explanation:

  • p=none: Specifies that no action should be taken on failing emails.
  • rua=mailto:dmarc-reports@yourdomain.com: Specifies that aggregate reports should be sent to `dmarc-reports@yourdomain.com`.

Example 2: Quarantine Policy

This DMARC record instructs receiving servers to quarantine failing emails and sends aggregate reports to `dmarc-reports@yourdomain.com`:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com;"

Explanation:

  • p=quarantine: Specifies that failing emails should be quarantined.
  • rua=mailto:dmarc-reports@yourdomain.com: Specifies that aggregate reports should be sent to `dmarc-reports@yourdomain.com`.

Example 3: Reject Policy with Subdomain Policy

This DMARC record instructs receiving servers to reject failing emails, sends aggregate reports, and applies the same policy to subdomains:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; sp=reject;"

Explanation:

  • p=reject: Specifies that failing emails should be rejected.
  • rua=mailto:dmarc-reports@yourdomain.com: Specifies that aggregate reports should be sent to `dmarc-reports@yourdomain.com`.
  • sp=reject: Specifies that the same reject policy should be applied to all subdomains of `yourdomain.com`.

Understanding DMARC Reports

DMARC reports provide valuable insights into your email authentication performance. There are two types of reports:

  • Aggregate Reports (rua): These reports are XML files that provide a summary of email authentication results over a period of time (typically daily). They include information about the number of emails that passed and failed SPF and DKIM checks, as well as the actions taken by receiving servers (e.g., quarantine, reject). Analyzing these reports can help you identify potential issues with your email configuration, such as misconfigured SPF records or DKIM signatures.
  • Forensic Reports (ruf): These reports provide detailed information about individual emails that failed authentication. They include the email headers, the results of SPF and DKIM checks, and the reasons for failure. These reports can be useful for investigating specific instances of spoofing or phishing, but they are less commonly used due to privacy concerns.

DMARC Report Example (Simplified):

<record>
  <row>
    <source_ip>192.0.2.10</source_ip>
    <count>100</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
</record>

This simplified example shows that 100 emails from the IP address 192.0.2.10 passed both DKIM and SPF checks, and the DMARC policy was set to “none” (monitoring mode).

Improving Email Deliverability: A Deep Dive into SPF, DKIM, and DMARC

Ensuring your emails reach the intended recipient’s inbox is a critical aspect of modern communication, whether for marketing campaigns, transactional notifications, or simple personal correspondence. Poor email deliverability can lead to missed opportunities, frustrated customers, and a damaged sender reputation. This article provides a comprehensive guide to understanding and implementing Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting & Conformance (DMARC) – the essential tools for improving your email deliverability and preventing spoofing.

By configuring these protocols correctly, you can significantly enhance the likelihood of your emails being delivered to the inbox rather than the spam folder, thus improving your overall communication effectiveness. We’ll explore the practical aspects of setting up SPF, DKIM, and DMARC, including detailed configuration examples and troubleshooting tips.

Understanding SPF: Authorizing Email Senders

Dpia slm rijk - Illustration depicting an SPF record authorizing various email senders for a domain, with arrows indicating the flow of email verification.

Sender Policy Framework (SPF) is an email authentication method designed to prevent sender address forgery. It allows domain owners to specify which mail servers are authorized to send email on behalf of their domain. Receiving mail servers can then check the SPF record of the sending domain to verify if the email originated from an authorized source. If the email fails the SPF check, it’s an indication that the email might be spoofed or forged.

Essentially, SPF acts as a “whitelist” for your domain, telling receiving servers, “These are the only servers allowed to send email using my domain.” This helps prevent spammers from forging your email address and sending malicious emails that appear to come from you.

Creating an SPF Record

An SPF record is a TXT record added to your domain’s DNS settings. It consists of a version number (“v=spf1”) followed by a series of mechanisms and qualifiers that define the authorized sending sources. Let’s look at some common mechanisms:

  • ip4: Allows specifying individual IPv4 addresses or ranges.
  • ip6: Allows specifying individual IPv6 addresses or ranges.
  • a: Allows specifying the A record of a hostname.
  • mx: Allows specifying the MX records of a domain.
  • include: Allows including another domain’s SPF record.
  • all: Specifies the policy for emails that don’t match any of the previous mechanisms.

Qualifiers modify the behavior of these mechanisms:

  • +: (Pass) The mechanism is allowed. This is the default if no qualifier is specified.
  • -: (Fail) The mechanism is not allowed.
  • ~: (SoftFail) The mechanism is not preferred, but accepted.
  • ?: (Neutral) The domain makes no assertion about whether the IP address is authorized.

Here are some practical examples:

Example 1: Basic SPF Record

This SPF record allows email from the server with the IP address 192.0.2.10 and any server listed in the MX records for your domain:

v=spf1 ip4:192.0.2.10 mx -all

Explanation:

  • v=spf1: Specifies the SPF version.
  • ip4:192.0.2.10: Allows email from the IPv4 address 192.0.2.10.
  • mx: Allows email from servers listed in the MX records for the domain.
  • -all: Any other source is explicitly disallowed (hard fail).

Example 2: Including a Third-Party Sender

If you use a third-party email service like SendGrid, Mailchimp, or Google Workspace, you’ll need to include their SPF records. For example, to include SendGrid:

v=spf1 include:sendgrid.net -all

Explanation:

  • include:sendgrid.net: Includes the SPF record of SendGrid, allowing them to send emails on your behalf. You would replace `sendgrid.net` with the appropriate domain for your third-party sender.
  • -all: Any other source is explicitly disallowed (hard fail).

Example 3: Multiple IP Addresses and Includes

This SPF record allows email from two specific IP addresses, servers listed in the MX records, and includes the SPF record for Google Workspace:

v=spf1 ip4:192.0.2.10 ip4:198.51.100.20 mx include:_spf.google.com -all

Explanation:

  • ip4:192.0.2.10: Allows email from the IPv4 address 192.0.2.10.
  • ip4:198.51.100.20: Allows email from the IPv4 address 198.51.100.20.
  • mx: Allows email from servers listed in the MX records for the domain.
  • include:_spf.google.com: Includes the SPF record for Google Workspace.
  • -all: Any other source is explicitly disallowed (hard fail).

Important Considerations

When configuring your SPF record, keep the following points in mind:

  • Limit DNS Lookups: SPF records have a limit of 10 DNS lookups. Using too many include mechanisms can exceed this limit, causing the SPF record to fail. Consider using IP addresses directly if possible.
  • Use Hard Fail (-all): A hard fail indicates a clear “no” and is generally preferred for stricter security.
  • Regularly Review and Update: As your email infrastructure changes (e.g., you switch email providers), update your SPF record accordingly.

Expert Tip: Use a tool like `dig` or `nslookup` to verify that your SPF record is correctly published in your DNS. You can also use online SPF record checkers to validate its syntax and identify potential issues.

dig yourdomain.com TXT

This command will query the DNS records for your domain and display the TXT records, including your SPF record (if present).

Implementing DKIM: Email Authentication with Digital Signatures

Dpia slm rijk - Diagram illustrating the DKIM signing process, highlighting the use of private and public keys for authentication.

DomainKeys Identified Mail (DKIM) is another crucial email authentication method that uses cryptographic signatures to verify the integrity and authenticity of emails. Unlike SPF, which focuses on authorizing sending servers, DKIM focuses on verifying that the email content has not been altered in transit and that it truly originated from the claimed sender.

DKIM works by adding a digital signature to the email header using the sender’s private key. Receiving mail servers can then retrieve the corresponding public key from the sender’s DNS record and use it to verify the signature. If the signature is valid, it confirms that the email’s content hasn’t been tampered with and that the sender is authorized to send email on behalf of the domain.

Generating DKIM Keys

The first step in implementing DKIM is to generate a key pair: a private key used for signing emails and a public key that will be published in your DNS record. You can generate DKIM keys using various tools, including OpenSSL or your email provider’s control panel.

Here’s an example of generating a DKIM key pair using OpenSSL:

openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.key

Explanation:

  • openssl genrsa -out private.key 2048: Generates a 2048-bit RSA private key and saves it to the file `private.key`. The 2048-bit key length is recommended for security.
  • openssl rsa -in private.key -pubout -out public.key: Extracts the public key from the private key and saves it to the file `public.key`.

Keep the private key secure. This key should only be accessible to your email server. You will use it to sign outgoing emails.

Creating the DKIM DNS Record

The public key needs to be published as a TXT record in your DNS. The format of the DKIM DNS record is as follows:

selector._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY;"

Explanation:

  • selector: A selector is a string used to identify the specific DKIM key. You can choose any selector, but it’s common to use “default” or a descriptive name. This allows you to rotate keys in the future without disrupting email flow.
  • _domainkey: This is a required prefix for DKIM records.
  • yourdomain.com: Replace this with your actual domain name.
  • v=DKIM1: Specifies the DKIM version.
  • k=rsa: Specifies the key type (RSA in this case).
  • p=PUBLIC_KEY: This is where you paste the actual public key generated earlier. Remove any line breaks from the public key before pasting it into the DNS record.

Example:

Let’s say your selector is “mail” and your public key is:

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwvk2p4dI635j10q6sRj
q2R29T8t1Y+Qx0j7v4Lq8Z0X9r8jWz6c3n2W0a5b7c8d9e0f1a2b3c4d5e6f7g
8h9i0j1k2l3m4n5o6p7q8r9s0t1u2v3w4x5y6z7a8b9c0d1e2f3g4h5i6j7k8l
9m0n1o2p3q4r5s6t7u8v9w0x1y2z3a4b5c6d7e8f9g0h1i2j3k4l5m6n7o8p9q
0r1s2t3u4v5w6x7y8z9a0b1c2d3e4f5g6h7i8j9k0l1m2n3o4p5q6r7s8t9u0v
1w2x3y4z5a6b7c8d9e0f1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0t1u
2v3w4x5y6z7a8b9c0d1e2f3g4h5i6j7k8l9m0n1o2p3q4r5s6t7u8v9w0x1y2z
3a4b5c6d7e8f9g0h1i2j3k4l5m6n7o8p9q0r1s2t3u4v5w6x7y8z9a0b1c2d3e
4f5g6h7i8j9k0l1m2n3o4p5q6r7s8t9u0v1w2x3y4z5a6b7c8d9e0f1a2b3c4d
5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0t1u2v3w4x5y6z7a8b9c0d1e2f3g4h5i6
-----END PUBLIC KEY-----

Your DKIM DNS record would look like this (replace `yourdomain.com` with your actual domain):

mail._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwvk2p4dI635j10q6sRj
q2R29T8t1Y+Qx0j7v4Lq8Z0X9r8jWz6c3n2W0a5b7c8d9e0f1a2b3c4d5e6f7g
8h9i0j1k2l3m4n5o6p7q8r9s0t1u2v3w4x5y6z7a8b9c0d1e2f3g4h5i6j7k8l
9m0n1o2p3q4r5s6t7u8v9w0x1y2z3a4b5c6d7e8f9g0h1i2j3k4l5m6n7o8p9q
0r1s2t3u4v5w6x7y8z9a0b1c2d3e4f5g6h7i8j9k0l1m2n3o4p5q6r7s8t9u0v
1w2x3y4z5a6b7c8d9e0f1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0t1u
2v3w4x5y6z7a8b9c0d1e2f3g4h5i6j7k8l9m0n1o2p3q4r5s6t7u8v9w0x1y2z
3a4b5c6d7e8f9g0h1i2j3k4l5m6n7o8p9q0r1s2t3u4v5w6x7y8z9a0b1c2d3e
4f5g6h7i8j9k0l1m2n3o4p5q6r7s8t9u0v1w2x3y4z5a6b7c8d9e0f1a2b3c4d
5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0t1u2v3w4x5y6z7a8b9c0d1e2f3g4h5i6;"

Important: Ensure there are no extra spaces or line breaks within the public key in the DNS record. This can cause the DKIM verification to fail.

Configuring Your Email Server for DKIM Signing

Next, you need to configure your email server to use the private key to sign outgoing emails. The configuration process varies depending on the email server you’re using. Here’s an example using Postfix with OpenDKIM:

  • Install OpenDKIM:
sudo apt-get install opendkim opendkim-tools
  • Configure OpenDKIM: Create the file /etc/opendkim.conf with the following content:
Syslog                  yes
SyslogSuccess           yes
LogWhy                  yes

UserID                  opendkim:opendkim
Socket                  inet:8891@localhost

KeyTable                refile:/etc/opendkim/KeyTable
SigningTable            refile:/etc/opendkim/SigningTable
TrustedAuthDomains      refile:/etc/opendkim/TrustedAuthDomains

ExternalIgnoreList      refile:/etc/opendkim/TrustedHosts
InternalHosts           refile:/etc/opendkim/TrustedHosts

OversignHeaders         From:Sender:Reply-To:Cc:Subject:Date
  • Create the KeyTable: Create the file /etc/opendkim/KeyTable with the following content:
mail._domainkey.yourdomain.com yourdomain.com:mail:/etc/opendkim/keys/yourdomain.com/mail.private

Replace `yourdomain.com` with your actual domain and `mail` with your selector.

  • Create the SigningTable: Create the file /etc/opendkim/SigningTable with the following content:
*@yourdomain.com mail._domainkey.yourdomain.com

Replace `yourdomain.com` with your actual domain and `mail` with your selector.

  • Create the TrustedHosts file: Create the file /etc/opendkim/TrustedHosts and add your domain and localhost:
127.0.0.1
localhost
yourdomain.com

Replace `yourdomain.com` with your actual domain.

  • Create the key directory and copy the private key:
sudo mkdir -p /etc/opendkim/keys/yourdomain.com
sudo cp private.key /etc/opendkim/keys/yourdomain.com/mail.private
sudo chown opendkim:opendkim /etc/opendkim/keys/yourdomain.com/mail.private
sudo chmod 600 /etc/opendkim/keys/yourdomain.com/mail.private

Replace `yourdomain.com` with your actual domain and `mail` with your selector. Also, replace `private.key` with the actual path to the private key file.

  • Configure Postfix: Add the following lines to /etc/postfix/main.cf:
milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = inet:127.0.0.1:8891
  • Restart OpenDKIM and Postfix:
sudo systemctl restart opendkim
sudo systemctl restart postfix

These steps configure Postfix to use OpenDKIM to sign outgoing emails.

Testing Your DKIM Configuration

After configuring DKIM, it’s essential to test that it’s working correctly. You can send an email to a DKIM analyzer service like `mail-tester.com`. This service will analyze your email and report whether the DKIM signature is valid.

Alternatively, you can examine the email headers of an email you send to a Gmail account. Look for the “Authentication-Results” header, which should indicate whether the DKIM check passed.

Example of a successful DKIM result in Gmail’s “Show Original” view:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@yourdomain.com header.s=mail header.b=...;
       spf=pass (google.com: domain of sender@yourdomain.com designates 192.0.2.10 as permitted sender) client-ip=192.0.2.10; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

This result indicates that DKIM, SPF, and DMARC all passed for the email.

Mastering DMARC: Policy and Reporting for Enhanced Security

Domain-based Message Authentication, Reporting & Conformance (DMARC) builds upon SPF and DKIM to provide a comprehensive email authentication framework. DMARC allows domain owners to specify how receiving mail servers should handle emails that fail SPF and/or DKIM checks. It also provides a reporting mechanism that allows domain owners to receive feedback on email authentication results, helping them identify and address potential issues like spoofing and phishing.

Essentially, DMARC acts as a policy layer on top of SPF and DKIM. It tells receiving servers what to do with emails that don’t pass authentication (e.g., quarantine, reject) and provides a way for domain owners to monitor email authentication activity.

Creating a DMARC Record

A DMARC record is a TXT record added to your domain’s DNS settings. It specifies the DMARC policy and reporting preferences. The DMARC record must be placed at the subdomain `_dmarc` of your domain.

The basic syntax of a DMARC record is:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=POLICY; rua=MAILTO_URI; ruf=MAILTO_URI;"

Explanation:

  • _dmarc.yourdomain.com: Specifies the location of the DMARC record in DNS. Replace `yourdomain.com` with your actual domain.
  • v=DMARC1: Specifies the DMARC version.
  • p=POLICY: Specifies the policy for handling emails that fail SPF and/or DKIM checks. Possible values are:
    • none: Monitoring mode. The receiving server takes no specific action. This is recommended for initial DMARC deployment.
    • quarantine: The receiving server should treat failing emails as suspicious. This typically means placing them in the spam folder.
    • reject: The receiving server should reject failing emails.
  • rua=MAILTO_URI: Specifies the email address to which aggregate reports should be sent. These reports provide a summary of email authentication activity.
  • ruf=MAILTO_URI: Specifies the email address to which forensic reports (failure reports) should be sent. These reports provide detailed information about individual emails that failed authentication. This is less commonly used due to privacy concerns.

Example 1: Monitoring Mode

This DMARC record is in monitoring mode and sends aggregate reports to `dmarc-reports@yourdomain.com`:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com;"

Explanation:

  • p=none: Specifies that no action should be taken on failing emails.
  • rua=mailto:dmarc-reports@yourdomain.com: Specifies that aggregate reports should be sent to `dmarc-reports@yourdomain.com`.

Example 2: Quarantine Policy

This DMARC record instructs receiving servers to quarantine failing emails and sends aggregate reports to `dmarc-reports@yourdomain.com`:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com;"

Explanation:

  • p=quarantine: Specifies that failing emails should be quarantined.
  • rua=mailto:dmarc-reports@yourdomain.com: Specifies that aggregate reports should be sent to `dmarc-reports@yourdomain.com`.

Example 3: Reject Policy with Subdomain Policy

This DMARC record instructs receiving servers to reject failing emails, sends aggregate reports, and applies the same policy to subdomains:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; sp=reject;"

Explanation:

  • p=reject: Specifies that failing emails should be rejected.
  • rua=mailto:dmarc-reports@yourdomain.com: Specifies that aggregate reports should be sent to `dmarc-reports@yourdomain.com`.
  • sp=reject: Specifies that the same reject policy should be applied to all subdomains of `yourdomain.com`.

Understanding DMARC Reports

DMARC reports provide valuable insights into your email authentication performance. There are two types of reports:

  • Aggregate Reports (rua): These reports are XML files that provide a summary of email authentication results over a period of time (typically daily). They include information about the number of emails that passed and failed SPF and DKIM checks, as well as the actions taken by receiving servers (e.g., quarantine, reject). Analyzing these reports can help you identify potential issues with your email configuration, such as misconfigured SPF records or DKIM signatures.
  • Forensic Reports (ruf): These reports provide detailed information about individual emails that failed authentication. They include the email headers, the results of SPF and DKIM checks, and the reasons for failure. These reports can be useful for investigating specific instances of spoofing or phishing, but they are less commonly used due to privacy concerns.

DMARC Report Example (Simplified):

<record>
  <row>
    <source_ip>192.0.2.10</source_ip>
    <count>100</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
</record>

This simplified example shows that 100 emails from the IP address 192.0.2.10 passed both DKIM and SPF checks, and the DMARC policy was set to “none” (monitoring mode).

Data PrivacyDPIAGovernmentRisk ManagementSLM

Share this article