The Sender Policy Framework is used for email service providers that sends emails on your behalf. It allows any email service listed in the SPF DNS records of a domain to send an email using that domain’s name.
When we forwarding an email, we don’t really send an email, and since we can’t control the sender, we can’t ask all of them to add @Emailforward.mx in their SPF DNS records.
OK, why are you then asking to add @Emailforward.mx in your SPF records?
The reason is to better handle bounces. A bounced email is any email message rejected by a recipient's mail server and returned to the original sender. A bounced email means that your message has not been delivered, and when this happens the mailer receives a notification of non-delivery. There are two different types of bounced emails: hard and soft. It’s important for us to know if the email successfully reached its destination or not.
One way to know that is via bounces; an email sent back to the return path email used in the “MAIL FROM command”. And this is exactly what SPF targets.
If @Emailforward.mx were to use the sender’s email in the MAIL FROM command without having our IPs listed on that sender’s domain, the email might be refused by the receiving server.
But since your domain is handled by @Emailforward.mx at the email level, it’s easier for us to ask you to add @Emailforward.mx on your SPF. That way, when we forward an email, we set the MAIL FROM domain part to yours (the recipient) since we are listed on your domain’s SPF records.
The special structure of the bounce email will be caught by @Emailforward.mx and handled properly.
Common Bounceback Messages
- Inbox is Full: This is a typical indication that the email recipient’s inbox is full and cannot accept any more messages. There is little you can do to resolve this error message unless you have another means of contacting that person to notify them of the full inbox. They should usually be able to resolve this issue by deleting old emails or raising their current mailbox quota.
- Email Account does not exist: If you send an email and get this message, it’s best to double check that you have spelled the recipient’s email address correctly. If you are sure that is is correct, the email account may have been deleted. If you have another means of contacting the recipients you may try notifying them of the error.
- IP Address Blacklisted/ Blocked: The bounce back message will typically refer to an IP address being blocked and will usually provide a url with more information as well. We ask that these types of bounce back messages be forwarded to us at firstname.lastname@example.org so that we can assist you in resolving this issue. You can also check to see if your domain name or IP address is blacklisted by using webapps such as MxToolbox.com.
- Greylisting/ Email Message Deferred: Typical messages due to greylisting will usually refer to an email message being “deferred.” Greylisting is a methodology utilized by some mail servers to deter spam. If you send a message to a server that uses greylisting and you are not on that server’s whitelist the receiving server will “temporarily reject” that message and will often return a message that is formatted very similar to a bounce back but will list the error as temporary instead of permanent. The sending server will attempt to resend the message at a later time, but the recipient will experience a delay in receiving the message. The best way to avoid greylisting is to ask anyone who uses greylisting on their server to add you to their whitelist so they can receive messages from you without delay.
What about DMARC and domain alignment issues?
DMARC ensures that the sender is truly allowed to send an email. This is done by verifying that SPF and DKIM (when present) are valid and that the domain used in either SPF or DKIM is the same as the sender.
We keep the SPF valid (because our servers are listed at the recipient’s domain) but we might break the domain alignment.
This occurs only when the DMARC records are present in an email that doesn’t have DKIM (Because domain alignment is for either SPF or DKIM, if a DKIM header is present, the alignment will be preserved so the email will be accepted).
When this occurs, our servers will handle this situation by rewriting the sender to stay compliant. This is a very specific situation (most domains, when implementing DMARC, already have DKIM in place).