Yahoo! and Google announced in late 2023 that starting in February 2024, all bulk senders are to have a proper DMARC policy in place and mail signing ( DKIM ) enabled if you wish to send mail to Gmail or Yahoo! email addresses. Google, especially, seems to have become significantly more strict about accepting messages that do not have valid SPF records in place, and mail signing enabled, regardless of message volume.
Due to these new policy changes, we strongly recommend getting all of the required changes implemented at your earliest convenience. Any messages sent to either Google or Yahoo! will likely begin being rejected and not delivered if the changes are not implemented in the very near future.
What is SPF / DKIM / DMARC?
SPF stands for Sender Policy Framework and is a DNS record that specifies a list of domains and/or IP addresses that may send email on your domains behalf.
DKIM stands for DomainKeys Identified Mail ( aka 'mail signing' ). DKIM uses a DNS record in conjunction with an encrypted 'signature' affixed to all emails sent via your domain. The DNS record acts as a lock and the signiture attached to your messages act as the key to this lock. Properly implemented DKIM ensures that a message has not changed since the message was signed.
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is a DNS record that specifies what happens when a receiving mail server cannot verify, via your SPF and DKIM records, that a sending party is who they say they are, and how that message should be handled.
Who is affected and why does any of this matter?
Originally, the information that was released by Google and Yahoo! stated that this new change would only affect those sending in excess of 5000 messages per day, however we are receiving many reports via our support team that Google, especially, seems to be implementing stricter guidelines on a much broader scale. It is always good practice to conform to the rules that the 'big players' are setting forth as they tend to have everyones best interests in mind.
SPF, DKIM, and DMARC are used in conjunction to not only prevent email spoofing, but also to reduce spam liability in the event that spam messages are sent claiming to be from your domain. When a domain or IP address is tied to a spamming incident, the domain and/or the IP address of the mail server responsible can be placed on one or more curated blacklists that drastically reduce which receiving mail servers will deliver your messages to your intended recipients. This is an especially bad scenario for webhosts such as Managed.com who often have multiple users' services tied to the same IP address.
How do I get everything in place so that my email messages continue to be delivered?
As stated above, two of the three requirements can be satisfied by simply setting up the correct DNS records. SPF and DMARC can both be implemented by anyone with access to your DNS records. Your DNS record provider is specified by your nameserver ( 'NS' ) records and can be looked up by doing a 'whois' lookup on your domain at sites such as
https://whois.domaintools.com/ or
https://www.whois.com/whois/ . Once you have determined where your DNS records are being served from, you can now set up SPF and DMARC records. See below for more detail:
SPF Record
SPF records are DNS records of type 'TXT'. A proper SPF record contains a list of authorized IP addresses and/or hostnames that may send mail on your domains behalf, as well as a 'directive' that determines how strict receiving mail servers should be if the sending party is NOT authorized via the SPF record. There are SPF record generators online such as at
SPFWizard.com and
MXToolbox that will generate the record for you. An example of a proper SPF record can be found below:
Record Type: TXT
Host/Name: <yourdomain>
Record Value: v=spf1 mx a include:relay.powerdnn.com ~all
The above record states that the domain is using SPF version 1, and that the MX record, the DNS 'A' record of the domain, and relay.powerdnn.com are all allowed to send mail on the domains behalf for which the record is implemented.
The '~all' portion is the directive that determines how strict receiving mail servers should be when a message does not pass the SPF check. The options are '~all' which tells the server to accept the message and flag it, however there is a stricter version, '-all', that tells the receiving mail server to reject the message. You may use the stricter directive if you are confident that you are not sending mail from any sources that are not listed in your SPF record, otherwise we recommend the less strict version, '~all' so that potentially legitimate messages are not bounced/rejected by mail servers on the receiving end of your email messages.
IMPORTANT: There can only be one SPF record in a domain's DNS records. If there are multiple, you will need to delete all but the most complete and accurate SPF record.
DMARC Record
DMARC records are also DNS records of type 'TXT' and tell receiving mail servers what to do if an incoming message does not pass the SPF record and/or DKIM checks. They contain a policy identifier as well as an email address to send reports to in the event that a nonconforming message is recieved. Much like SPF, there are DMARC record generators such as
MXToolbox . An example of a proper DMARC record can be found below:
Record Type: TXT
Host/Name: _DMARC.<yourdomain>
Record Value: v=DMARC1; p=none; rua=mailto:<an email address on your domain>
The above should be fairly self explanatory however take note of the details as they're important - the hostname of the record must be preceded by '_DMARC', and the email address specified in the 'rua=mailto:' portion should be an email address that is checked regularly, but not necessarily your main email address. Something along the lines of postmaster@yourdomain.com, dmarc@yourdmain.com, mailadmin@yourdomain.com etc.
The 'p=none' portion of the above record is a directive that does not change how mail is handled, that is, it is still delivered to the recipients inbox. There are two other options, 'p=quarantine' which will deliver the message, but likely to the recipients spam/junk folder, and 'p=reject' which will bounce the message with an error stating as such.
DKIM Setup
The final portion to bring your email in to full compliance is to set up DKIM or mail signing. DKIM requires yet another DNS record however this record is specified by the mail server software and as such must be provided by a Managed.com support technician. If your mail services are hosted here at Managed.com, please reach out to support@managed.com or submit a ticket via your customer portal and we will be happy to provide the required record.