Training FAQ
FAQ Detail
Review the full answer below, then return to the searchable FAQ list.
Emails sent from GamePlanPro™ come from ucora.com. Why can't they come from my domain?
When we send emails on behalf of customers, there are technical rules that determine whether those emails get delivered or flagged as spam. These rules exist to prevent fraud and spoofing.
What creates the issue
It can look like an email is coming from a customer’s domain, such as yourcompany.com, even though it is actually sent by our system at ucora.com. This is often called email masquerading. The message appears to come from one domain, but is sent by another.
Email providers treat this as high risk.
Modern email systems use SPF and DKIM to verify that the sending server is allowed to send email for the domain shown in the From address. If an email claims to be from yourcompany.com but is sent from ucora.com, most receiving servers will see that as suspicious. Messages may be blocked, delayed, or sent to spam.
Why we send from ucora.com
To avoid these delivery problems, emails must be sent from ucora.com, which is the domain that actually sends them. This allows the messages to pass SPF and DKIM checks and reach inboxes reliably.
Even though the email is sent from ucora.com, we can still clearly indicate that the message is sent on behalf of yourcompany in the sender name and email content.
How replies are handled
Many systems use a DoNotReply address, but that can frustrate recipients who need to respond.
We use a Reply-To header instead. This tells the recipient’s email client where replies should go. The email may be sent from ucora.com, but when someone clicks Reply, their response goes to the correct person at yourcompany.com.
Why DoNotReply still matters
Reply-To is not foolproof. Some non-standard email clients ignore it. Replies can also break if the message is forwarded.
In those cases, replies go to the From address instead. To prevent confusion, the From address must be a controlled address such as:
donotreply@yourcompany.ucora.com
Summary
What creates the issue
It can look like an email is coming from a customer’s domain, such as yourcompany.com, even though it is actually sent by our system at ucora.com. This is often called email masquerading. The message appears to come from one domain, but is sent by another.
Email providers treat this as high risk.
Modern email systems use SPF and DKIM to verify that the sending server is allowed to send email for the domain shown in the From address. If an email claims to be from yourcompany.com but is sent from ucora.com, most receiving servers will see that as suspicious. Messages may be blocked, delayed, or sent to spam.
Why we send from ucora.com
To avoid these delivery problems, emails must be sent from ucora.com, which is the domain that actually sends them. This allows the messages to pass SPF and DKIM checks and reach inboxes reliably.
Even though the email is sent from ucora.com, we can still clearly indicate that the message is sent on behalf of yourcompany in the sender name and email content.
How replies are handled
Many systems use a DoNotReply address, but that can frustrate recipients who need to respond.
We use a Reply-To header instead. This tells the recipient’s email client where replies should go. The email may be sent from ucora.com, but when someone clicks Reply, their response goes to the correct person at yourcompany.com.
Why DoNotReply still matters
Reply-To is not foolproof. Some non-standard email clients ignore it. Replies can also break if the message is forwarded.
In those cases, replies go to the From address instead. To prevent confusion, the From address must be a controlled address such as:
donotreply@yourcompany.ucora.com
Summary
- Sending from the customer’s domain without authorization causes spam problems
- Sending from ucora.com ensures reliable delivery
- Reply-To handles normal replies cleanly
- A DoNotReply address is still required for edge cases