How to Avoid Spam Filters: Focusing on Email Authentication

Getting your emails delivered to the inbox can feel like a constant battle against spam filters. While many factors contribute to deliverability, email authentication is a critical and often overlooked aspect. This article will delve into the specifics of email authentication protocols – SPF, DKIM, and DMARC – and provide practical examples to help you configure them correctly, significantly improving your chances of landing in the inbox rather than the spam folder.

Understanding SPF (Sender Policy Framework)

SPF records specify which mail servers are authorized to send emails on behalf of your domain. Failing to set up an SPF record or having an incorrectly configured record can lead to your emails being flagged as spam.

At its core, SPF is a DNS record that lists all the IP addresses or hostnames allowed to send email using your domain. When a receiving mail server gets an email claiming to be from your domain, it checks your SPF record. If the sending server’s IP address isn’t listed in your SPF record, the email is more likely to be marked as spam. Creating an SPF Record An SPF record is a TXT record added to your domain’s DNS settings. The syntax can seem intimidating at first, but it becomes easier with a little understanding. Here’s a breakdown of common SPF record elements:

• v=spf1: This indicates the SPF version being used (currently, only spf1 exists). It’s mandatory and must be the first element in the record.
• ip4: Specifies an IPv4 address that is authorized to send email.
• ip6: Specifies an IPv6 address that is authorized to send email.
• a: Authorizes the IPv4 and IPv6 addresses associated with the specified hostname.
• mx: Authorizes the IPv4 and IPv6 addresses associated with the mail exchangers for the domain.
• include: Includes the SPF record of another domain. This is useful if you use a third-party service like Google Workspace or SendGrid to send emails.
• -all: A hard fail. If an email doesn’t match any of the previous mechanisms, it should be rejected.
• ~all: A soft fail. If an email doesn’t match any of the previous mechanisms, it should be accepted but marked as suspicious. It’s generally recommended to use `-all` for stricter enforcement.
• ?all: Neutral. The receiving server should accept the email and do not mark it as suspicious.

It’s crucial to only have one SPF record per domain. Having multiple SPF records can cause SPF checks to fail. Practical SPF Examples Let’s look at a few practical examples to illustrate how to create and configure SPF records. Example 1: Basic SPF Record for a Single Mail Server

v=spf1 ip4:192.0.2.1 -all

This SPF record allows only the mail server with the IP address 192.0.2.1 to send emails for your domain. Any email originating from a different IP address will fail the SPF check and might be marked as spam. Example 2: SPF Record Including Google Workspace

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

If you use Google Workspace (formerly G Suite), you need to include Google’s SPF record. This example includes Google’s SPF record and uses a soft fail (~all). Example 3: SPF Record with Multiple IP Addresses and a Hostname

v=spf1 ip4:192.0.2.1 ip4:198.51.100.0/24 a:mail.example.com -all

This SPF record allows emails from the IP address 192.0.2.1, the entire IP range 198.51.100.0/24, and any IP addresses associated with the hostname mail.example.com. Example 4: SPF Record including a Third-party hubspot-email-marketing-tactics-to-boost-roi/" class="internal-link" title="3 Hubspot Email Marketing Tactics to Boost ROI">Email Marketing Service

v=spf1 include:servers.mailchimp.com ~all

This record allows Mailchimp’s servers to send emails on your behalf. Consult the documentation of your email marketing service for their specific SPF include directive. Testing Your SPF Record After creating or modifying your SPF record, it’s crucial to test it to ensure it’s configured correctly. You can use online SPF record checkers like:

• MXToolbox: https://mxtoolbox.com/spf.aspx
• Dmarcian: https://dmarcian.com/spf-survey/

These tools will check your SPF record for syntax errors and validate its effectiveness. Simply enter your domain name, and the tool will provide detailed information about your SPF record. Common SPF Mistakes to Avoid

• Having Multiple SPF Records: As mentioned earlier, having multiple SPF records for a domain is a common mistake that can cause SPF checks to fail.
• Incorrect Syntax: SPF records are sensitive to syntax errors. Double-check your record for typos and ensure that all elements are correctly formatted.
• Missing the `include` Directive for Third-Party Services: If you use third-party email services, make sure to include their SPF records in your SPF record.
• Using `+all`: This allows any server to send email on your behalf, defeating the purpose of SPF. Avoid it at all costs.
• Exceeding the 10 DNS Lookup Limit: SPF records can trigger DNS lookups when using mechanisms like `include`, `a`, or `mx`. SPF specifications limit the number of DNS lookups to 10. Exceeding this limit can cause SPF checks to fail, even if your record is syntactically correct. Flattening your SPF record by replacing `include` statements with the actual IP addresses can help avoid this limit, but requires more maintenance.

Implementing DKIM (DomainKeys Identified Mail)

DKIM provides an encrypted digital signature that verifies the sender and ensures the message hasn’t been altered during transit. This helps receiving mail servers confirm that the email genuinely originated from your domain.

DKIM works by adding a digital signature to the header of your email messages. This signature is generated using a private key, which is kept secret on your mail server. The corresponding public key is published in your domain’s DNS records. When a receiving mail server receives an email with a DKIM signature, it retrieves the public key from the DNS record and uses it to verify the signature. If the signature is valid, it confirms that the email was indeed sent by the owner of the domain and hasn’t been tampered with. Generating a DKIM Key Pair The first step in implementing DKIM is to generate a DKIM key pair, consisting of a private key and a public key. You can use various tools to generate these keys, including OpenSSL. Example using OpenSSL:

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

This command generates a 2048-bit RSA key pair. The `private.key` file contains the private key, which you should keep secure on your mail server. The `public.key` file contains the public key, which you will publish in your DNS record. Alternative using `opendkim-genkey`: If you have `opendkim-tools` installed, you can use the `opendkim-genkey` command:

opendkim-genkey -t -d example.com -s mail

This command generates a private key file named `mail.private` and a DNS record snippet. `-d` specifies the domain, and `-s` specifies the selector (explained below). You’ll need to configure your mail server to use the `mail.private` file. Adding the DKIM Record to DNS The public key needs to be added to your domain’s DNS as a TXT record. The name of the TXT record follows a specific format: `selector._domainkey.yourdomain.com`, where “selector” is a name you choose to identify the key (e.g., “mail”). The value of the TXT record is the public key, formatted according to the DKIM specification. It typically looks like this:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwWx6VjJ9vQ0hT8fV73w79Jys5qJvL+l5v8WvQnQ6Z0U7xZ8Y0bJ2a3R9iU6o+p4iO3l3K6j8g7h5f4v2c1b9a8z7x0y5w4v3u2r1t9s8q7p6n5m4l3k2j1i0h8g7f6e5d4c3b2a1z9y8x7w6v5u4t3s2r1q0p9o8n7m6l5k4j3i2h1g0f8e7d6c5b4a3z2y1x9w8v7u6t5s4r3q2p1o0n9m8l7k6j5i4h3g2f1e0d8c7b6a5z4y3x2w1v9u8t7s6r5q4p3o2n1m0l9k8j7i6h5g4f3e2d1c0b8a7z6y5x4w3v2u1t9s8r7q6p5o4n3m2l1k0j9i8h7g6f5e4d3c2b1a0z9y8x7w6v5u4t3s2r1q0p9o8n7m6l5k4j3i2h1g0f8e7d6c5b4a3z2y1x9w==

Breaking down the components:

• v=DKIM1: Specifies the DKIM version.
• k=rsa: Specifies the key type (RSA).
• p=: Contains the base64-encoded public key.

So, if your domain is example.com and you choose “mail” as your selector, the DNS record name would be `mail._domainkey.example.com`. Example DNS Record Configuration:

Hostname	Type	Value
mail._domainkey.example.com	TXT	v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwWx6VjJ9vQ0hT8fV73w79Jys5qJvL+l5v8WvQnQ6Z0U7xZ8Y0bJ2a3R9iU6o+p4iO3l3K6j8g7h5f4v2c1b9a8z7x0y5w4v3u2r1t9s8q7p6n5m4l3k2j1i0h8g7f6e5d4c3b2a1z9y8x7w6v5u4t3s2r1q0p9o8n7m6l5k4j3i2h1g0f8e7d6c5b4a3z2y1x9w==

Remember to replace the example public key with your actual public key. Configuring Your Mail Server for DKIM Signing Once you have the DKIM key pair and the DNS record, you need to configure your mail server to use the private key to sign outgoing emails. The specific steps will vary depending on your mail server software. Here are examples for Postfix and Exim: Postfix Configuration (using OpenDKIM): 1. Install OpenDKIM:

apt-get install opendkim opendkim-tools

2. Edit `/etc/opendkim.conf`:

Socket                  inet:8891@localhost
PidFile                 /var/run/opendkim/opendkim.pid
User                    opendkim:opendkim
SigningTable            refile:/etc/opendkim/SigningTable
KeyTable                refile:/etc/opendkim/KeyTable
TrustAnchorFile         /usr/share/dns/root.key

3. Create `/etc/opendkim/SigningTable`:

*@example.com    mail._domainkey.example.com

4. Create `/etc/opendkim/KeyTable`:

mail._domainkey.example.com example.com:mail:/etc/opendkim/keys/mail.private

5. Create the keys directory and move the private key:

mkdir /etc/opendkim/keys
mv mail.private /etc/opendkim/keys/
chown opendkim:opendkim /etc/opendkim/keys/mail.private
chmod 600 /etc/opendkim/keys/mail.private

6. Configure Postfix in `/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

7. Restart OpenDKIM and Postfix:

systemctl restart opendkim
systemctl restart postfix

Exim Configuration: 1. Install `exim4-daemon-heavy` (if not already installed). 2. Install `dkim-filter`. 3. Generate keys (as shown earlier). 4. Configure Exim to use the DKIM filter. This typically involves modifying the Exim configuration file (`/etc/exim4/exim4.conf.localmacros` or similar, depending on your setup). The exact configuration varies, but you’ll need to specify the selector, domain, and private key location. Consult the Exim documentation and DKIM filter documentation for precise instructions. Testing Your DKIM Configuration After configuring DKIM, you need to test it to ensure that your emails are being signed correctly. You can send an email to a DKIM checker service. These services will analyze the email headers and verify the DKIM signature. Here are a couple of options:

• Mail-Tester: https://www.mail-tester.com/
• Check-Auth: Send an email to `check-auth@verifier.port25.com`

These services will provide a detailed report, indicating whether the DKIM signature is valid and any potential issues with your configuration. Look for a “PASS” result for DKIM. DKIM Selectors and Key Rotation A DKIM selector allows you to use multiple DKIM keys for the same domain. This is useful for key rotation. You can rotate your DKIM keys periodically for security purposes. When you rotate keys, you generate a new key pair, update the DNS record with the new public key, and configure your mail server to use the new private key. You can use a different selector for each key, allowing you to transition to the new key without interrupting email delivery. To rotate keys, generate a new key pair with a different selector (e.g., “mail2”). Add the corresponding DNS record for `mail2._domainkey.example.com`. Then, update your mail server configuration to use the new private key (`mail2.private`). Once you’re confident that the new key is working correctly, you can remove the old DNS record and private key.

Configuring DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC builds upon SPF and DKIM, allowing you to tell receiving mail servers what to do with emails that fail authentication checks. It also provides reporting, so you can monitor your email authentication performance and identify potential issues.

DMARC essentially acts as a policy layer on top of SPF and DKIM. It allows you to specify how receiving mail servers should handle emails that fail SPF and/or DKIM checks. You can choose to have these emails quarantined (sent to spam), rejected outright, or treated normally. DMARC also provides a reporting mechanism, allowing you to receive reports from receiving mail servers about the authentication results of emails claiming to be from your domain. This valuable feedback helps you identify and address any authentication issues. Creating a DMARC Record A DMARC record is another TXT record that you add to your domain’s DNS settings. The name of the record is always `_dmarc.yourdomain.com`. The value of the record specifies your DMARC policy and reporting preferences. Here’s a breakdown of common DMARC record elements:

• v=DMARC1: Specifies the DMARC version. This is mandatory and must be the first element.
• p=: Specifies the policy to be applied to emails that fail DMARC authentication. Possible values are:
  • `none`: Take no specific action. The receiving server should treat the email as normal. This is useful for monitoring.
  • `quarantine`: The receiving server should quarantine the email (e.g., send it to the spam folder).
  • `reject`: The receiving server should reject the email outright.
• rua=: Specifies the email address(es) to which aggregate reports should be sent. Aggregate reports provide a summary of the authentication results of emails claiming to be from your domain.
• ruf=: Specifies the email address(es) to which forensic reports (also known as failure reports) should be sent. Forensic reports provide detailed information about individual emails that failed authentication. This is often disabled for privacy reasons.
• adkim=: Specifies alignment mode for DKIM. `r` for relaxed, `s` for strict.
• aspf=: Specifies alignment mode for SPF. `r` for relaxed, `s` for strict.
• fo=: Specifies failure reporting options. `0` to generate a report if all underlying authentication checks fail. `1` to generate a report if either DKIM or SPF fails. `d` to generate a DKIM failure report, and `s` to generate an SPF failure report.
• rf=: Specifies the format for forensic reports. `afrf` is the standard.
• ri=: Specifies the interval (in seconds) at which aggregate reports should be sent. The default is 86400 (one day).
• pct=: Specifies the percentage of emails to which the DMARC policy should be applied. This allows you to gradually roll out a DMARC policy. A value of 100 means that the policy should be applied to all emails.

Practical DMARC Examples Here are a few practical examples of DMARC records: Example 1: Monitoring Mode

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;

This record sets the policy to “none,” meaning that no specific action should be taken on emails that fail authentication. It also specifies that aggregate reports should be sent to `dmarc-reports@example.com`. This is a good starting point for monitoring your email authentication performance. Example 2: Quarantine Policy

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=100;

This record sets the policy to “quarantine,” meaning that emails that fail authentication should be sent to the spam folder. It also specifies that aggregate reports should be sent to `dmarc-reports@example.com`, and that the policy should be applied to 100% of emails. Example 3: Reject Policy

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:forensic-reports@example.com; pct=100;

This record sets the policy to “reject,” meaning that emails that fail authentication should be rejected outright. It also specifies that aggregate reports should be sent to `dmarc-reports@example.com` and forensic reports should be sent to `forensic-reports@example.com`, and that the policy should be applied to 100% of emails. Example 4: Strict Alignment for SPF and DKIM

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; aspf=s; adkim=s;

This record sets the policy to “reject” and enforces strict alignment for both SPF (`aspf=s`) and DKIM (`adkim=s`). Strict alignment means that the “From” address in the email must exactly match the domain used for SPF and DKIM authentication. This provides a higher level of security but can be more complex to implement. Implementing DMARC Gradually It’s generally recommended to implement DMARC gradually, starting with a policy of “none” and gradually increasing the policy to “quarantine” and then “reject.” This allows you to monitor your email authentication performance and identify any potential issues before implementing a more restrictive policy. You can use the `pct=` tag to gradually roll out a DMARC policy. For example, you could start with `pct=10`, meaning that the policy should only be applied to 10% of emails. Then, you could gradually increase the percentage over time. Analyzing DMARC Reports DMARC reports provide valuable insights into your email authentication performance. Aggregate reports provide a summary of the authentication results of emails claiming to be from your domain. Forensic reports provide detailed information about individual emails that failed authentication. Analyzing these reports can help you identify:

• Legitimate emails that are failing authentication.
• Unauthorized senders who are spoofing your domain.
• Configuration errors in your SPF or DKIM records.

There are various tools and services available to help you analyze DMARC reports. These tools can automatically parse the reports and provide you with a clear and concise overview of your email authentication performance. Examples include:

• Dmarcian
• Proofpoint
• Valimail

Beyond Authentication: Additional Factors for Inbox Placement

While SPF, DKIM, and DMARC are crucial, they are not the only factors that determine whether your emails reach the inbox. Email providers consider various other elements when filtering spam.

Email authentication establishes your legitimacy, but factors such as your sender reputation, email content, and recipient engagement also play significant roles in determining whether your emails land in the inbox or the spam folder. A holistic approach to email deliverability requires attention to these additional areas. Sender Reputation Your sender reputation is a measure of how trustworthy your email sending practices are perceived to be by email providers. It’s based on factors like your IP address history, sending volume, and complaint rates. A poor sender reputation can significantly impact your deliverability, even if your email authentication is properly configured. Here are some tips for maintaining a good sender reputation:

• Use a Dedicated IP Address: Using a dedicated IP address gives you more control over your sender reputation. Shared IP addresses can be affected by the sending practices of other users.
• Warm Up Your IP Address: If you’re using a new IP address, gradually increase your sending volume over time. This helps email providers establish a positive reputation for your IP address.
• Maintain Low Complaint Rates: Encourage recipients to unsubscribe rather than marking your emails as spam. Keep your complaint rates below 0.1%.
• Authenticate Your Emails: As discussed earlier, SPF, DKIM, and DMARC are essential for establishing your legitimacy and protecting your sender reputation.
• Monitor Blacklists: Regularly check your IP address and domain against email blacklists. If you find yourself on a blacklist, take immediate action to get removed. Tools like MXToolbox can help with this.

Email Content The content of your emails can also affect your deliverability. Spam filters analyze email content for suspicious words, phrases, and patterns. Avoid using spam trigger words and ensure that your emails are well-written and relevant to your recipients. Here are some tips for creating email content that avoids spam filters:

• Avoid Spam Trigger Words: Be mindful of the words and phrases you use in your emails. Avoid using words like “free,” “guaranteed,” “urgent,” and “limited time offer” excessively. A quick online search will reveal lists of common spam trigger words.
• Use Proper Grammar and Spelling: Poor grammar and spelling can make your emails look unprofessional and suspicious. Proofread your emails carefully before sending them.
• Avoid Excessive Use of Capital Letters and Exclamation Points: Using too many capital letters and exclamation points can make your emails look like spam.
• Include a Clear Unsubscribe Link: Make it easy for recipients to unsubscribe from your emails. This shows that you respect their preferences and are not trying to trap them.
• Use Alt Text for Images: Always include alt text for images in your emails. Some email clients block images by default, so alt text ensures that recipients can understand the content of your email even if the images are not displayed.
• Maintain a Good Text-to-Image Ratio: Don’t rely solely on images to convey your message. Use a good balance of text and images. Emails with only images are more likely to be flagged as spam.

Recipient Engagement Recipient engagement is a measure of how recipients interact with your emails. Email providers track metrics like open rates, click-through rates, and complaint rates to determine the quality of your emails and your sender reputation. Here are some tips for improving recipient engagement:

• Send Relevant and Personalized Emails: Tailor your emails to the interests and preferences of your recipients. Use personalization to make your emails more engaging.
• Segment Your Email List: Segment your email list based on demographics, interests, and behavior. This allows you to send more targeted emails to specific groups of recipients.
• Clean Your Email List Regularly: Remove inactive subscribers from your email list. Sending emails to inactive subscribers can hurt your engagement rates and sender reputation.
• Use A/B Testing: Experiment with different subject lines, email content, and sending times to see what works best for your audience.
• Ask Recipients to Add You to Their Address Book: This can help improve deliverability by ensuring that your emails are not filtered into the spam folder.

Infrastructure and Technical Considerations The technical infrastructure you use to send emails can also impact deliverability. Ensure that your mail server is properly configured and that you are following best practices for email sending.

• Use a Reliable Mail Server: Choose