Open topic with navigation

Sender Authentication

Mailbox providers use authentication methods to evaluate whether messages that appear to be from your organisation are legitimate so they can block or filter email from fraudulent senders. For example, a scammer could craft an email that looks like it comes from your organisation and solicit donations to a site they own. If the mailbox provider can’t verify whether the email is from you, the scammer could receive gifts donors think they're giving to your organisation.

Fraudulent senders can change either of the “from” addresses an email message contains to make it seem like it’s from your organisation:

To help mailbox providers verify when a sender is legitimate, our email system supports multiple authentication methods for your domain. Since you own your domain, we rely on you to manage the authentication for it.

Note: Mailbox providers use a variety of methods to evaluate messages, so passing or failing authentication checks doesn’t always directly correlate to inbox placement. We recommend you take a comprehensive approach to deliverability to increase the likelihood your messages reach recipients.

Click to expand dropdownSender Policy Framework (SPF)

The Sender Policy Framework (SPF) protocol is an authentication method that enables receiving mail systems to verify the mail servers that are authorised to send email on behalf of a domain.

When a mailbox provider uses SPF authentication, they compare the server that appears in the message header — also known as the long or internet header — to the sending servers that are listed in the Domain Name System (DNS) record for the “envelope from” address.

To authorise our system to send emails on your behalf, access the DNS record for your domain through your domain name registrar — such as GoDaddy, Network Solutions, or Name.com — and add a TXT record to it for your SPF information.

Note: Add a TXT record with SPF information for each domain you use to send email.

  • If your organisation uses its own office email server and Blackbaud is the only ESP that sends email on your behalf, include:

    • v=spf1 +mx +include:blackbaudhosting.com ?all

  • If your organisation uses multiple ESPs, include:

    • +include:blackbaudhosting.com

  • If your organisation uses its own office email server and Blackbaud is the only ESP that sends email on your behalf, include:

    • v=spf1 +mx +include:outboundmail.convio.net ?all

  • If your organisation uses multiple ESPs, include:

    • +include:outboundmail.convio.net

Note: Don’t forget to also include the other email servers that are authorised to send on your behalf.

Click to expand dropdownDomainKeys Identified Mail (DKIM)

The DomainKeys Identified Mail (DKIM) protocol is an authentication method that digitally signs part of an email message so that receiving mail systems can verify it wasn’t altered after it was originally sent.

To use it, a sender decides which elements of a message they want to include for the signature — such as the header and body or individual fields in the header — and then configures their system to encrypt those selections with a private key when they send email. When a mailbox provider receives a message with a DKIM signature, they use the public key the sender lists for their domain in the DNS to “unlock” the private key.

By default, our email system provides generic 1024-bit DKIM authentication which encrypts fields in the header of messages you send with a private key. When mailbox providers receive the messages, they use the public key we publish for our domain to unlock it.

Note: If a generic DKIM signature is not sufficient for your organisation's unique needs, or if you'd like to implement a DMARC policy, you can request a custom DKIM signature for your domain.

Note: If a generic DKIM signature is not sufficient for your organisation's unique needs, or if you'd like to implement a DMARC policy, you can request a custom DKIM signature for your domain.

Tip: If your organisation published DKIM public keys with less than 1024-bits, including those with the convio1 key, we recommend you delete them.

Click to expand dropdownDomain Message Authentication Reporting Conformance (DMARC)

Since various ESPs might legitimately send messages on behalf of a domain, it can be difficult for a sender to know which of their messages authenticate properly with mailbox providers. To address this issue, Domain Message Authentication Reporting and Conformance (DMARC) provides a standard way for senders to establish policies for mailbox providers to use when email from them doesn’t pass SPF and DKIM.

The policies outline the criteria providers should use to determine whether messages pass or fail the checks and how they should handle messages that don’t pass, such as whether they should accept them, send them to the spam folder, or reject them entirely. The policies also detail the information mailbox providers should include in periodic reports to senders about which messages authenticate, which do not, and why.

To use DMARC, your organisation must configure SPF and use a custom DKIM signature. We recommend you update all email servers that use your domain — such as the ones your organisation uses locally — before you publish a DMARC policy. Given the complexity of this authentication method, and the significant impact improper configuration could have, we recommend you consult with your own email specialist before you implement it.