Emails are not getting to your recipients?

[Administrator]

Suddenly your emails are not getting to your recipients? Below is an explanation of what’s going on behind the scenes and what could be causing the trouble.

BTW: This is not documentation to fix it yourself (contact us if having sending issues)!

With spammers using various email spoofing techniques to get their junk mail delivered, ISPs and hosts have come up with some techniques of their own to stop them.

One of the effective tools of anti-spoofing and anti-spamming is email authentication (if configured correctly), in your cPanel it consists of two major components – SPF and DKIM records.

The SPF Record

Nowadays the vast majority of spam emails have fake data in the «From» field. Spammers and fraudsters use special tools to send their mail on behalf of a real owner of the e-mail address.

The SPF record (acronym for Sender Policy Framework) is an effective and simple method which lets you avoid such issues. If your domain name has a correct SPF record then you can be sure nobody is able to send fake e-mails on behalf of your domain name.

The main idea of SPF record is that an owner of domain name publishes the information about IP addresses that are authorized to send mail from this domain name. The receiving server compares the information in the envelope sender address with the information published by domain name owner. If these details match then e-mail is delivered.

NOTE 1: sometimes cPanel automatically fetches incorrect server outgoing IP address. This happens when we have changed the IP address of your website (ex: switching from shared to dedicated IP or vice versa). Get in touch with us and we will gladly re-check if the correct IP is added to your SPF record.

NOTE 2: SPF record has its own specific syntax. It is strongly recommended to get familiar with SPF record syntax documentation if you are going to customize the record yourself.

NOTE 3: SPF record is added to your domain DNS zone as a TXT record. There are cases when it’s required to add another TXT record to verify your domain name ownership for some service. It is not recommended to modify existing DNS zone records yourself (unless you really know what you are doing), actually it’s recommended that you contact us and leave any of that required configuration to us.

The SPF record for each domain should look something like this: “v=spf1 a include:webterritory.net ~all” There may be some added content (which is OK), however should contain what is shown here.

The DKIM Record

DKIM (DomainKeys Identified Mail) is another way of e-mail authentication. This method uses information about domain which is published by the domain owner. That information allows receiving server to verify if the e-mail message was sent by legal owner of that domain name.

Once the TXT record which contains DKIM has been added to the DNS zone a special code is added to the headers of outgoing e-mails. Receiving servers compare these headers with the information in DNS zone and if it matches then the e-mail is delivered.

NOTE: DomainKeys(DK) and DomainKeys Identified Mail (DKIM) are separate things.

Reverse DNS Resolution – No PTR Record found? (only if you have a dedicated IP)

You will need to contact us to setup a correct PTR record for you if you are using your own domain with a dedicated IP as the mail server. You should ask that this record be the same as the hostname of your SSL website (so you can access your email using SSL/TLS).

Only the organization which controls an IP can configure PTR records. PTR record queries are sent to the owner of the IP address which is our upstream provider, unlike other DNS queries which are sent to the DNS server of whoever owns the domain.

Advanced DNS stuff – regular clients can stop reading here.

Dmarc Record (experimental; setup only on webterritory.net)

DMARC Records are published via DNS as a text(TXT) record (not available in the cPanel). They will let receiving servers know what they should do with non-aligned email received from your domain.

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a mechanism for improving mail handling by mail-receiving organizations. The ultimate purpose of DMARC, according to RFC-7489 is to provide a “mechanism by which email operators leverage existing authentication and policy advertisement technologies to enable both message-stream feedback and enforcement of policies against unauthenticated email. Email originating organizations utilize DMARC in order to express domain-level distribution policies/preferences for message validation, disposition, and reporting.

Here are some example DMARC TXT records (_dmarc.your_domain.com IN TXT) you can modify for your own use. Of course, replace “your_domain.com” and “postmaster@your_domain.com” with your actual domain and email address.

Important: Before creating a DMARC record for your domain, you must first set up DKIM authentication.

“v=DMARC1; p=none; rua=mailto:postmaster@your_domain.com”

In this TXT record, if a message claims to be from your domain.com and fails the DMARC checks, no action is taken. Instead, all of these messages appear on the daily aggregate report sent to “postmaster@your_domain.com.”

“v=DMARC1; p=quarantine; pct=5; rua=mailto:postmaster@your_domain.com”

In this TXT record, if a message claims to be from your domain.com and fails the DMARC checks, quarantine it 5% of the time. Then email daily aggregate reports to “postmaster@your_domain.com.”

“v=DMARC1; p=reject; rua=mailto:postmaster@your_domain.com, mailto:dmarc@your_domain.com”

In this TXT record, if a message claims to be from “your_domain.com” and fails the DMARC checks, reject it 100% of the time. Then email daily aggregate reports to “postmaster@your_domain.com” and “dmarc@your_domain.com.”

SOA Refresh Value

This value configures how often a name server should check it’s primary server to see if there has been any updates to the zone which it does by comparing Serial numbers. It is not recommended if it is less than 20 minutes or greater than 12 hours.

SOA Expire Value

Each DNS host has their own interface, but you are looking for either a setting labeled Expire Value or you might have to enter your SOA details manually. If you have to enter your SOA then the Expire value will be second to last number in the SOA.

Your DNS records are hosted on two or more DNS servers that are supposed to be in regular contact with each other so that they have up to date copies of your DNSrecords. The Expire Value setting tells each slave server how long it is allowed to continue giving out authoritative replies after it has no longer heard from the master server.

RFC 1912 recommends 1209600 – 2419200 seconds (14-28 days).

[Author]

Posts