A message-size rejection can happen before the receiving server evaluates all message authentication. It can also appear after an upstream server has accepted a message and a later hop applies a smaller limit. Diagnose the size condition at the rejecting hop rather than treating every permanent rejection as an SPF, DKIM or DMARC defect.
Distinguish size from policy and storage
RFC 3463 defines X.3.4 as a message too big for the receiving system and X.2.3 as a message length exceeding an administrative limit for the mailbox. These differ from X.2.2 mailbox full. Read the full diagnostic because products may add their own limits, units and explanatory wording. A generic “552” label alone does not establish the exact configured restriction. RFC 3463 sections 3.3 and 3.4.
Authentication failures concern identities, signatures or policy rather than the number of message octets. Reducing size is not a DKIM repair; changing signed content can itself invalidate a signature, so an authorized replacement must pass through the normal signing workflow. Conversely, authorizing another IP in SPF does not increase a recipient's permitted message size. Keep the two investigations separate unless independent evidence shows both are failing.
Read the advertised SIZE capability correctly
The SMTP SIZE extension lets a server advertise support and optionally a maximum message size in its EHLO response. A supporting client can supply an estimated size with MAIL FROM, allowing rejection before transmitting the entire message. SIZE without a number conveys no fixed-maximum information; SIZE 0 explicitly indicates no fixed maximum is in force. Neither guarantees acceptance. Later processing and other hops can still impose constraints. RFC 1870 sections 3 and 4.
For RFC 1870 SIZE, count message octets including CRLF line endings, headers, MIME structure and encoded content, but exclude the DATA terminating dot and extra dot-stuffing bytes. Do not count only the attachment file. Base64 encoding expands binary data, and line breaks and surrounding message parts add more bytes. See RFC 2045 section 6.8. Provider interfaces may display rounded units differently. Record the measured octets and the exact advertised or documented limit rather than comparing two unexplained “MB” labels.
Compare controlled variants
Create two authorized variants that differ only in the size-relevant content. Preserve the smaller and larger serialized sizes and the SMTP stage of each outcome. An illustrative pair could contain the same short explanatory text, with a large attachment replaced by an approved access-controlled file link. Do not assume that a file link is suitable for confidential material or that the recipient has access.
RFC 5321 section 4.5.3.1.7 requires support for a message size of at least 64K octets, including headers. The following 100,000-octet limit is above that protocol minimum, not a recommended provider setting.
For a hypothetical arithmetic check, suppose the same endpoint advertises SIZE 100000. An assumed 115,900-octet message exceeds that limit by 15,900 octets; an assumed 20,100-octet replacement is 79,900 octets below it. The first can be rejected at MAIL FROM; the second is eligible for further processing but is not guaranteed acceptance. These numbers are invented, not measurements or executed SMTP results. They do not describe any provider's attachment ceiling.
Repair the narrowest relevant constraint
Ask the owner of the rejecting system whether the size is an intentional service limit or an organization-controlled setting. If the business need can be met with a smaller file, use that route rather than raising limits across the entire mail system. If a limit change is authorized, consider resource consumption, malware scanning and downstream compatibility before applying it.
Do not keep retrying the same permanently rejected content unchanged. Confirm that the original was not accepted at another hop or for another recipient, then submit the approved replacement with a clear relationship to the earlier attempt. Preserve its own message and queue identifiers. A new message is a new delivery event, even if the user regards it as the same attachment.
Close with the measured message size, identified rejecting limit and outcome of the corrected attempt. Leave inbox placement and recipient access to linked content as separate checks.
Separate the limit from the workaround
- Measure: count the complete serialized message using the SIZE definition, not just the attachment.
- Locate: capture the rejecting hop, command stage, diagnostic and applicable limit.
- Repair: choose an approved smaller message or access-controlled delivery method.
- Recheck: record the replacement size and per-recipient result; do not assume every downstream limit matches.
- Close: confirm recipient access separately from SMTP acceptance.