When you send emails, mailbox providers (such as Gmail, Outlook, AOL, and Yahoo) identify if emails are legitimate or are sent by a spammer or phisher. This is why setting up email authentication is important.
There are three established methods used to verify a sender's identity.
SPF, DKIM, and DMARC Authentication
To authenticate your domain, log in to your eduCRM account:
- Go to Settings/Advanced.
- Enter your domain name and click Configure Domain. DKIM, DMARC, and SPF authentication records will generate automatically in the Connect a Domain pop-up window.
To complete authentication, log in to your DNS provider:
- Log in to your DNS provider and locate your DNS record settings.
- Copy and paste the records from the table below into the proper fields in your DNS provider.
Most DNS providers will require the following items to set up these DNS records:
Choose the relevant type for each row (CNAME or TXT).
- Name or Host
Copy and paste the "Name" for each DNS record, like acdkim1._domainkey (most common) or the full CNAME "Name" like acdkim1._domainkey.mydomain.com (less common). Which one you should use depends on whether your DNS provider automatically adds the domain name to the DNS records you create. If you are unsure which to use, look at the format of other DNS records in your settings (do they include the domain name in the Name or Host field?) or ask your DNS provider.
- Value or Record
Copy and paste the "Value" shown for each DNS record.
TTL means "Time Till Live." Use the recommended or default setting of your DNS host. If there isn't a default setting, we recommend 300 (5 minutes).
This process will vary slightly based on your DNS provider.
Email authentication does not solve all deliverability problems, such as whether or not the recipient wants the email. However, authentication does solve the problem of determining who the email is coming from.
A sender who follows best practices, such as sending high-quality, personalized emails to prospective and current students, parents, faculty, staff, and alums and performing regular list hygiene, will typically see higher deliverability when using email authentication.
Authentication allows good senders to further solidify their reputation and protect their domain from bad senders who may try to hijack it.
Learn More About SPF, DKIM, DMARC, and Other Authentication Methods
SPF (Sender Policy Framework) records are TXT records on your domain that authorize specific servers to send mail using your domain name. When you configure your domain, this process generates a Mailserver Domain where you point your domain to us via a CNAME record. This allows eduConverse to serve the necessary SPF record for you. As long as you have set up the Mailserver Domain in your DNS records, SPF will be fully covered in your account.
DKIM (Domain Keys Identified Mail) is a signature any sender can apply to their email messages. This signature clarifies that the message's sender is actually the sender and not a bad actor. You can use any domain as the signature. For example, "Ansley College" will sign their messages with the "ansleycollege.edu" domain to confirm that the message was sent by the College.
This is accomplished by inserting a hidden, cryptographic signature into your email header (automatic when your domain is authenticated) and then placing a public key on your website's DNS that verifies the authenticity of this signature.
DKIM will help prevent spoofing and phishing of your domain. An added benefit is that it allows Mailbox Providers such as Gmail, Microsoft, and Oath (Yahoo, AOL, Verizon) to track the email reputation of your sending domain.
If the reputation of your sending domain is stronger than the reputation of the sending IPs, Mailbox Providers may default to your sending domain reputation, which could improve your email performance.
DMARC (Domain-based Message Authentication, Reporting & Conformance) is a standard that builds on top of SPF and DKIM. It allows the domain owner to create a policy that tells mailbox providers (such as Google or Microsoft) what to do if the email fails SPF and DKIM checks.
When you configure your domain, we will help you set up a basic DMARC record as a bare minimum.
You can think of this simple DMARC record as a placeholder, and it will not impact the messages you send. Still, it will satisfy Gmail and Yahoo's requirement for a basic DMARC record. If you want to secure your domain further with DMARC, consider our partner product, DMARC Digests.
DMARC supports three main policy configurations:
- Indicates that emails should be treated normally if DMARC fails. It is equivalent to not having a DMARC record, although you can still use DMARC's reporting features.
- Indicates that emails should be delivered to the spam folder if the DMARC check fails.
- Indicates that emails should be bounced (not delivered to the recipient) if the DMARC check fails.
Using a DMARC policy of "Quarantine" or "Reject" will require a proper DKIM record setup for your sending domain. Otherwise, all your mail from eduCRM will fail the DMARC test. This will filter it to the spam folder ("Quarantine") or block it entirely ("Reject"). Ensure you set up DKIM for all your sending domains before setting up a strict DMARC record.
Some of the many benefits of setting up DMARC include:
- DMARC records prevent someone from spoofing your domain
- DMARC is necessary for setting up Brand Indicators for Message Identification (BIMI).
- DMARC is a requirement for basic delivery to many email providers like Gmail and Yahoo
Additional authentication methods
BIMI (Brand Indicators for Message Identification) is a new standard based on DMARC. It allows domain owners who have implemented DMARC in Enforcement mode (e.g., Quarantine or Reject) to purchase a Verified Mark Certificate (VMC) to display a BIMI logo for their brand in email messages. This gives recipients an easy way to identify trusted messages visually.
As BIMI is such a new standard, it has yet to be widely adopted by domain owners or mailbox providers, and you do not need to set up BIMI. However, if you are interested in learning more, you can review the following sites:
SenderID is an authentication standard that was created by Microsoft and intended as a replacement for SPF. However, Sender ID has since been deprecated and is no longer used; therefore, you do not need to configure it.
If you have any Sender-ID records currently set in DNS (TXT record starting with spf2.0), you should remove them.
SPF (record starting with v=spf1) is still the industry's widely supported and recommended authentication standard.