Sending using your organization's domain

Smart.pr supports sending emails using your organization's domain. Using your domain is important for the following reasons:

At Smart.pr we believe in targeted personalized email. You want your email message to be trusted and using your organization's domain is a big part of this.
Your organization domain's DMARC policy may not allow this method of sending. As a result, the email messages you send from Smart.pr will either be flagged as spam or not delivered at all.
Email clients might display domain information that recipients can't relate to the actual domain of the sender's email address.

To overcome these limitations, you need to allow Smart.pr to send email messages on behalf of your organization's domain. We use SendGrid (an email delivery platform) to send out all customer messages as DMARC-compliant emails.

Sending domain authentication (delegation) is achieved by adding CNAME records to your DNS. These records are generated in the Smart.pr application when going through the sending domain authentication process. The default subdomain is pr.

pr.example.com.            -> u9307341.wl092.sendgrid.net.
pr._domainkey.example.com. -> pr.domainkey.u9307341.wl092.sendgrid.net.
pr2._domainkey.example.com.-> pr2.domainkey.u9307341.wl092.sendgrid.net.

An SPF record is setup on the SPF domain (pr.example.com) allowing SendGrid to

send via one of our IP addresses:

$ dig +short pr.example.com txt
u9307341.wl092.sendgrid.net.
"v=spf1 ip4:192.254.121.79 -all"

An MX record is setup allowing SendGrid to receive email messages (required for

accepting bounce messages):

$ dig +short pr.example.com mx
u9307341.wl092.sendgrid.net.
20 mx.sendgrid.net.

DKIM records are setup to make the DKIM public key accessible. The private key

remains safely with SendGrid.

$ dig +short pr._domainkey.example.com txt
pr.domainkey.u21085665.wl166.sendgrid.net.
"k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

$ dig +short pr2._domainkey.example.com txt
pr2.domainkey.u21085665.wl166.sendgrid.net.
"k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

After completing the authentication, email messages will be sent on your behalf of your organization's domain as follows:

RFC5321.MailFrom: pr.example.com
RFC5322.From: alice@example.com
SPF domain pr.example.com
DKIM domain: example.com
DKIM selectors: pr, pr2

IP Address

All customer email messages are sent from the same IP address. This IP address has a great reputation and is monitored by us.

$ dig +short o1.email.pressmailings.com
192.254.121.79

Warning: Please refrain from adding this IP address to your own SPF records. The sending domain authentication process sets up the needed SPF record for you specifically. If we ever add or migrate IP addresses your configuration will likely break.

Sending from a subdomain

If it is undesirable to use your organization domain due to your organizational email policy, we would suggest creating a subdomain like press.example.com, specifically for press mailings. Please note that you have to ensure email messages sent to user@press.example.com can be delivered.

MX records must be created for the domain to receive email messages. Create an MX record for press.example.com, otherwise the Smart.pr verification email will never arrive.
Setup up mail forwarding from @press.example.com to @example.com so mail can be delivered to a real mailbox.
Sender domain authentication is still required, except it is done using the sub-domain.

In this case, email messages will be sent on your behalf of your organization's domain as follows:

RFC5321.MailFrom: pr.press.example.com
RFC5322.From: alice@press.example.com
SPF domain pr.press.example.com
DKIM domain: press.example.com
DKIM selectors: pr, pr2