Proper domain authentication is essential for email deliverability. Without it, your emails are likely to be flagged as spam, damaging your domain reputation.
By verifying your domain, you signal to receiving email servers that your messages are legitimate and originate from a trusted source, significantly improving deliverability and protecting your domain's reputation.
This guide will walk you through the essential domain authentication protocols — SPF, DKIM, and DMARC — and provide specific instructions on how to set them up within the Method platform.
Understanding the Core Authentication Protocols
There are three key pillars of email domain authentication:
SPF (Sender Policy Framework): SPF is a TXT record added to your domain's DNS settings that lists the IP addresses or servers authorized to send emails on behalf of your domain. It acts like a guest list, telling receiving servers to only accept mail from approved senders.
DKIM (DomainKeys Identified Mail): DKIM adds a digital signature to your emails using public-key encryption. This signature verifies the email's authenticity and ensures that the content hasn't been tampered with in transit. It's like a digital wax seal on your email.
DMARC (Domain-based Message Authentication, Reporting, and Conformance): DMARC builds upon SPF and DKIM by allowing you to define policies for how receiving servers should handle emails that fail SPF or DKIM checks. It also provides reporting features, giving you insight into who is sending email using your domain and whether their messages are being authenticated.
Setting Up Authentication Within Method
Method simplifies the process of setting up these crucial authentication records. Here's how to configure MX, SPF, DKIM, and DMARC for your custom domain within the platform:
Click your Profile icon in the upper-right and then click Account Settings.
Select Communication.
By default, you will be in the Email Settings tab. Within the Domains section, click the Add Domain Button (only visible when sending via Method Servers).
You will be prompted for a domain name. Type the domain of the email addresses you’ll use to send your emails.
e.g If you send emails from sales@best4youservices.com, enterbest4youservices.com.
Uncheck
Use automatic security (recommended).
Adding New DNS Records Provided by Method
Method utilizes unique sub-domains for its email sending services. This approach ensures that adding the necessary authentication records for Method will not require you to modify your existing DNS records or interfere with your current email flow or other services. You will be adding new records specifically for Method's sending on your behalf.
Method will provide you with three distinct records to add to your domain's DNS settings:
MX Record: This record, with a unique subdomain (e.g., em1234), enables the "return-path." The return-path is a separate email header that directs bounce notifications and unsubscribe requests to a designated address, providing valuable feedback on your email deliverability. Add this as a separate MX record.
TXT (SPF) Record: This SPF record will also use a unique subdomain (e.g., em1234), scoping the SPF authorization specifically to Method's sending services. This prevents any conflict with existing SPF records you might have for other email services. The record will likely include sendgrid.net as Method uses SendGrid for email sending. Add this as a separate TXT record.
TXT (DKIM) Record: Method will provide a DKIM record with a unique selector specific to their service. Add this as a separate TXT record. This new record will not conflict with any existing DKIM records. The priority for this record can typically be left as 0. Method uses a 1024-bit DKIM key for signing your emails.
Configuring DMARC Policy
DMARC plays a crucial role in telling receiving servers what to do with emails that don't pass SPF or DKIM checks and links the sender's domain in the "From" header to the DNS records. Configuring a DMARC policy is required to send emails from an authenticated domain via Method. Without it, your emails may not be delivered.
You have two primary approaches for configuring your DMARC policy with Method:
Set DMARC Policy to p=none (Recommended for simplicity):
Pros: This is the simplest approach and is fully compatible with Method's default setup.
Cons: This policy provides limited control over how unverified emails are handled. While it allows for DMARC reporting, emails failing authentication will still likely be delivered (potentially to the spam folder).
Implement Your Own DKIM and DMARC Policies:
Pros: This option gives you full control and flexibility over your email authentication policies.
Cons: This requires a more advanced setup, potentially involving a dedicated SendGrid account, and may incur additional costs. You will need to configure your own DKIM records for your primary domain and set your DMARC policy accordingly.
For step-by-step instructions, see SendGrid’s guide: DKIM Records Explained.
On DMARC Policies
If you choose to implement your own DKIM and a stricter DMARC policy (like p=quarantine or p=reject) you must ensure that DKIM is properly set up for all sending domains you use with Method. Emails sent via Method will fail DMARC checks if a strict policy is in place without the corresponding DKIM record being correctly configured.
DMARC policies are defined in a TXT record added to your DNS. The three main policy configurations are:
p=none: receiving servers should treat emails normally even if DMARC fails. Useful for monitoring and receiving reports without impacting deliverability.
p=quarantine: emails that fail DMARC checks should be moved to the recipient's spam or junk folder.
p=reject: emails that fail DMARC checks should be bounced and not delivered to the recipient at all.
Optional: Add a DMARC RUA Tag
To gain valuable insights into potential domain spoofing or phishing attempts, you can include a rua tag in your DMARC record. This tag specifies an email address where aggregate DMARC reports will be sent. These reports provide data on email traffic using your domain, including authentication results.
Be aware that the volume of these reports can be very high, potentially hundreds or thousands per day depending on your email volume. It is highly recommended to use an email address solely dedicated to receiving these reports and consider using a DMARC report processing service to help analyze and make sense of the data.
Troubleshooting & FAQs
My records aren't verifying - what should I do?
Double-check that you have precisely copied each DNS record provided by Method into your domain host's settings. Even a small typo can prevent verification.
If you chose manual setup, confirm that you haven't accidentally duplicated SPF records or added conflicting DKIM records from other services you might be using.
Verify that the records were added as the correct type (MX, TXT).
How long does verification take?
DNS changes can take anywhere from a few minutes to a full 48 hours to propagate globally. If it has been longer than 48 hours and your records are still not verified, contact your domain host's support or Method's support team for assistance.
Will setting this up affect other email services I use?
Adding SPF, DKIM, or DMARC records can potentially impact how other services (like your primary email provider or other marketing platforms) send emails from your domain.If you use multiple services to send emails, your SPF record needs to include all authorized senders. When using Method's unique subdomain SPF record, this concern is mitigated for emails sent through Method, as it is scoped to the subdomain. However, your primary domain's SPF record still needs to be correct for other services.
Similarly, ensure that all services sending email from your domain are configured with the appropriate DKIM settings for your domain. If you implement your own DKIM and a strict DMARC policy, this becomes even more critical.